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
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
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
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
On 9 Jan 2019, at 20:48, Christian Grün wrote:
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.
This is not true. A long running REST operation (executing a bunch of ADD and STORE commands) blocks parallel reads. A long running REST operation as in my case has serious impact on reading operations in parallel over WebDAV…the WebDAV connection timed out in my case.
Andreas
On 10 Jan 2019, at 6:53, Christian Grün wrote:
This is not true.
Sounds like a communication problem. My impression is that we are both right. Did you read our documentation?
The documentation perhaps does not explain the behavior properly. but anyway… A write operation in any database should not block parallel read operations. Read-last-committed as isolation is what one expect but not blocking of read operations until the end of the write transaction.
Andreas
The documentation perhaps does not explain the behavior properly. but anyway… A write operation in any database should not block parallel read operations. Read-last-committed as isolation is what one expect but not blocking of read operations until the end of the write transaction.
It seems we can’t make you happy with BaseX, Andreas. Sorry for that. In order to allow concurrent reads during updates and at the same time preserve all ACID guarantees and other guarantees that we can give to our users, we might switch to an MVCC architecture one day in future. It might get reality if we find enough sponsors out there.
The current architecture works fine in practice, though; it is applied in commercial use cases in which millions of datasets are stored and thousands of concurrent updates and reads are performed in realtime by hundreds of users. However, building such applications requires some knowledge and experience with BaseX. One crucial issue is, for example, that your update operations will be fast.
basex-talk@mailman.uni-konstanz.de
-
Andreas Jung -
Christian Grün