On 20/10/12 02:26, James Leigh wrote:
> I reviewed the changes and noticed that you changed the behaviour of the
> MemoryStore and NativeStore from a (mostly) monotonic view that allows
> concurrent transactions (so long as there are no pending writes
> operations) to serializable were there is only ever at most one active
I assume we're talking about the SAIL API, or rather the locking
strategy in place in the SailConnection base implementation. But can you
elaborate a bit on what exactly the problem is that you see? Is there a
problem in the API design, or are we talking about a problem in the base
As far as I can tell the locking strategy in place is the same as ever,
and the SAIL still supports concurrent reads (as long as no write
operations are pending).
Note that for read operations, I have not enforced at the SAIL level
that an explicit transaction should be started. Perhaps you assumed that
I did? I am still of two minds about that.
begin() obtains a read lock, then obtains a update lock to block
concurrent updates (so add/remove operations are serialized). But it
releases the read lock as the method exits, so AFAICT a concurrent read
operation should not be blocked as long as no updates are actually
underway. Of course, a concurrent call to begin() will block (because it
can not obtain the update lock), but if a concurrent thread just
executes the read operation directly (without invoking begin()), it
shouldn't be blocked.
But this is a tricky bit of operational logic, so if I've overlooked
something, can you point it out?
> This could have a negative effect on perform. Applications that create
> transactions for read operations will switch from concurrent read-only
> transactions in 2.6 to at most one active transaction at a time in
> revision 11986.
I did not consciously design it this way, so if that is the case we're
talking about a unintended side effect.
Possibly, a way around the issue is to introduce the notion of a
read-only connection at the SAIL level (by optionally supplying the
getConnection() method with a READ_ONLY mode flag) - this could steer
how aggressively the connection locks stuff when begin() is called.
If we design it this way, we can enforce that at the SAIL level, begin()
is always called, even for read-only operations, without losing the
possibility of concurrent reads. It will be tricky though to support
this at the Repository level, because SailRepository currently maintains
a 1:1 correspondence between RepositoryConnection and SailConnection -
and that will have to change if we implement this.
> I am not apposed to the change, as the OptimisticRepository wrapper from
> AliBaba can be used to provide concurrent (read and write) transaction
> support with monotonic, snapshot, or serializable isolation levels, but
> we need to document how this will effect applications moving from 2.6 to
I'm not sure about relying on Alibaba to provide something so
fundamental to the framework, but it would help if I understood a bit
better what the exact problem is.