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
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")))