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