Hi Marco,
even if %basex:lock can be added to specific function calls, it will only be considered before the full query is evaluated. As a consequence, your current query will only be evaluated if no other updating query with CONFIG locks is running at the same time.
Apart from that, the store functions are not handled by our transaction management. Instead, they will be immediately executed, and we do our best to ensure that parallel store operations do not result in inconsistent states (basically by treating each store update as an atomic operation). We may need to clarify this in our documentation.
What has been your motivation for adding entries to the store in parallel?
Best, Christian
Marco Lettere m.lettere@gmail.com schrieb am Mi., 22. Jan. 2025, 17:21:
Dear all,
I'm wondering why the code in [1] is not working as expected. Expected means getting back a map with 100 keys.
Instead I get a random number of keys which denotes the fact (proved by tracing) that the map in store is updated concurrently without respecting the lock annotations.
Is there a way to obtain synchronized access to key/values of the default store?
Thank you.
Kind regards,
Marco.
[1]
declare %updating %basex:lock('CONFIG') function local:write($k as xs:string) { store:put("config", map:put(store:get("config"), $k, random:integer(10))) };
let $s1 := store:put("config", map{}) let $s2 := xquery:fork-join(for $i in (1 to 100) return function(){ local:write("key" || $i) }) return count(map:keys(store:get("config")))