Re: [Exist-development] [Exist-open] Performance of concurrent read queries.

[Jason S. <js...@in...>]

When a deadlock occurs, the part of the code that is responsible for starting and controlling the transaction must catch the deadlock exception, rollback to the previous state, and restart the operation.  One thread in the deadlock proceeds, the other thread in the deadlock must yield and restart.

Currently, eXist is not fully transactional, so there are conditions on restarting.

From: pet...@go... [mailto:pet...@go...] On Behalf Of Peter Crowther
Sent: Thursday, September 02, 2010 6:18 AM
To: Jason Smith
Cc: eXist development
Subject: Re: [Exist-development] [Exist-open] Performance of concurrent read queries.

On 1 September 2010 18:09, Jason Smith <js...@in...<mailto:js...@in...>> wrote:
Other databases do have high concurrency.  I don't know about XML databases though.  I've worked with one in particular that is commercial.  It has a collection-based locking model, and it throws deadlock errors occasionally.  When this happens, you rollback and start over.
I think I just had an allergic reaction to a pronoun :-).

Let's just take the pronoun out of that paragraph and be clear about what we're talking about here.  In particular, what is "you"?

In order to be able to start over, "you" must be able to roll back to a point that is well-defined.  This generally requires transaction boundaries to be controllable from "you"; if not, "you" cannot determine the point from which to start over.  In general, the only sensible "you" for this purpose is the calling application.

Does eXist have transaction boundaries that are controllable from the calling application?  If not, what other values of "you" might make sense for this approach?

- Peter