Hi all,
## Notes on Implementing Non-Locking
If implementing such non-locking I’d propose following:
- If documented at all, provide a large red warning message in the docs. Something about really do not use this feature if you don’t know the internals very well and voiding all support or something like that. - We already have some locking options. I’d recommend to use them, but disable the recognition of which databases to lock (thus do not call the visitor, I think it should be in `AQuery#databases`). Do not break locking for commands, they’re able to recognize what they need to lock very well. - Add some function like `boolean lockTest(String db)`. See if `db` is actually locked before opening it. There is one function always called in the `Data` class, this is a great point for such a hook, I used it when writing a test implementation of optimistic concurrency control for my [thesis]. If the lock is not set, fail early (throw some QueryException). Your XQuery developers (and database consistency) will be very thankful.
The current `DBLocking` implementation expects conservative locking, thus fetching all locks in the beginning of the transaction and will fail if you try to fetch more locks afterwards. If you fetch locks using the existing XQuery options you will not have any problems with that. We used that to prevent deadlocks to prevent failure in case of external side effects which occur rather often, but this resulted in rather bad parallelism for complex queries (which means —- sadly —- most relevant ones).
## Efforts on Further Improved Concurrency Control
We have some discussion on extending our locking for use cases which can deal with external side effects (thus, restarting the transaction in case of deadlocks), but this is a rather large project as it delves deep in the core _and_ large parts of the query processor, but this will definitely take some time and effort. The concurrency control part is not too complicated itself (and there is at least a somewhat working, yet rather hacky, concept implementation), but making BaseX capable of gracefully terminating and restarting transactions will take some effort.
Kind regards from Lake Constance, Jens
[thesis]: http://kops.ub.uni-konstanz.de/handle/urn:nbn:de:bsz:352-235049