Are you saying that a write transaction blocks pending READ requests
until the transaction has been committed?
No. What I was trying to say is that we deliberately designed REST requests to be atomic transactions. If you perform multiple updates in a single REST operation, you can be sure that a concurrent read operation will see the state before or after the first operation, but no state in-between.
But it’s correct that, for the very same reason, we are using a multiple reader and single writer transaction model (on database level). This goes hand in hand with the Pending Update List semantics of the W3 XQuery Update Facility. Check out our documentation to learn more about transactions and updates in BaseX [1,2].
[1] http://docs.basex.org/wiki/Transactions [2] http://docs.basex.org/wiki/Update
Am Mo., 7. Jan. 2019, 18:29 hat Andreas Jung lists@zopyx.com geschrieben:
Are you saying that a write transaction blocks pending READ requests until the transaction has been committed?
On 7 Jan 2019, at 11:14, Christian Grün wrote:
Hi Andreas,
If you send multiple commands via a single REST operation, they will be treated as a single transaction. In order to preserve the ACID principles, no other operations will run in parallel. If you want to run concurrent operations, you should be fine if you send your commands one by one via multiple REST requests.
Best Christian
On Fri, Jan 4, 2019 at 7:35 AM Andreas Jung lists@zopyx.com wrote:
For development purposes I am running basehttp in foreground. The WebDAV endpoint seems to block while I run a larger import for REST
with lots of ADD and STORE commands within one
<commands>..</commands> section. The WebDAV connection times out…what
is the explanation for this?
Andreas