Any consideration given to something like XLP?

Hello, I have been giving some thought to concurrency and rollback/recovery as we continue to evolve our Java EE application that uses BaseX as its XQuery, (XQuery update facility) engine. From reading the BaseX Transactions section I concluded that BaseX locking is done at the database level. I can imagine this could ultimately become the major bottleneck in a "reactive cloud" application, has anyone considered the value of implementing a more granular locking mechanism like XLP (Xpath Locking Protocol) on which several academic papers have been written? Are there any similar ideas on the horizon for transactional commit/rollback for XML data? Thanks to the group (and Christian in particular) for such great help, advice and support. Mike.

Dear Mike, I agree, database locking can be a potential bottleneck in application with high loads. Talking about more fine granular locking concepts for XML, I haven’t read much about XPath-based locking (have you dived further into that topic?). I remember node-based locking approaches, e.g. the one from Haustein & Härder (see e.g. [1] for a short introduction) or the another one from Xu et al [2]. From the latter approaches I know pretty well, and from the first approach I would assume, that it’s ambitious and costly to get this done for the results of all the different kinds of update that can be done with XQuery Update – but I’ll be glad to learn more about this. As far as I know, document-based locking is the most popular approach in existing XML databases, and this is something we could introduce in BaseX as well. I invite you and everyone else to continue the discussion that has been started in [3]. Talking about rollbacks, one great thing about the semantics of XQuery Update is that all possible checks will be performed before the update takes place. As a result, the complete update will be rejected if one of these checks fails, and no errors can take place that could happen if all updates were immediately performed. Obviously, this won’t save us against hardware or power failures. In practice, there are various alternative to tackle this shortcoming. If high availibility is crucial (i.e., if it’s no option to create regular backups of the full database), new data can be saved in incremental databases, which can later be merged with the main database. Cheers, Christian [1] https://www.researchgate.net/profile/Theo_Haerder/publication/228910533_taDOM_A_Synchronization_Concept_for_the_DOM_API/links/00b49517aeb68b7bb0000000.pdf [2] http://www.ic.unicamp.br/~wainer/old/criwg/32.pdf [3] https://github.com/BaseXdb/basex/issues/1083