Hi Marco, When I try your code (with 10.7 or 11.6 ) I get
[XPTY0004] Function is updating: %updating fn() as empty-sequence()... Which is what I would expect from the hint in the documentation [1] Do you not get this error message? /Andy [1] https://docs.basex.org/main/XQuery_Functions#xquery:fork-join On Mon, 27 Jan 2025 at 16:41, Marco Lettere <m.lett...@gmail.com> wrote: > Thanks for checking into this Christian. > > I'm experimenting with some sort of workflow oriented programming because > our projects are getting more and more complex and we'd like to have a way > of "standardizing" some patterns and getting a bit of introspection and > observability of what happens to a complex workflow. > > We'd love to use the store as a shared memory among functions annotated as > tasks for many reasons such as keeping a global log of the workflow, > reducing dependency on function signatures or chaining together tasks > executed in subsequent continuations (aka subworkflows). > > Those are kind of things that you can benefit from when using workflow > engines. But we don't want to rely on those because they have a huge impact > in terms of provisioning and maintenance. So we wanted to check whether a > light weight solution in code is viable. > > I'm currently rewriting the code to use a DB instead of the store. But it > would have been so nice to have it without requiring an external db > server... But for example, as soon as I have two tasks running in parallel > (fork-join) and they want to add a log line to the sequence of logs that > introduces the risk of loosing data. > > Hope it clears up the intent even if a bit convoluted explanation. :-) > Ciao, > M. > > On 27/01/25 17:15, Christian Grün wrote: > > 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.lett...@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"))) >> >>
