multi user store enhancement

["Pill, Juergen" <Ju...@softwareag.com>]

Hello,

I want to suggest following enhancement in the (child/father) store API:

Each retrieveXXX(...) Method receives an additional associated
retrieveXXXForUpdate(...) method.

The reason behind this extension is, that in a multi user scenario, the DB
may start the transaction too late. 
Scenario:
2 threads are reading say a RevisionDescriptor for the same URL nearly in
the same time frame and thread1 modifies the RD and commits it.  After this
thread2 modifies the (read and now out-dated) RD, stores it and tries to
commit the changes. Depending on the isolation level, the used DB and their
transaction implementation, following situations could occur:
1) The (out dated) RD is stored and committed in the DB without a problem
==> semantical inconsistence (lost update problem)
2) The RD can not be stored ==> Exception
3) The RD can not be committed ==> Exception
If the Slide kernel would call the xxxForUpdate methods in case of the e.g.
RD wants to be changed in this thread (this has to be implemented yet) the
stores/DBs could open their transaction a lot earlier and/or depending on
the used DB/store technology implement their own synchronization/waiting
mechanism. This would increase through put (thus performance) and reduce the
amount of not successful commands. The old retrieveXXX(...) would have the
semantic read-for-read.

Does this make sense?

Best regards

Juergen Pill

Re: multi user store enhancement

[Remy Maucherat <re...@apache.org>]

> Hello,
>
> I want to suggest following enhancement in the (child/father) store API:
>
> Each retrieveXXX(...) Method receives an additional associated
> retrieveXXXForUpdate(...) method.
>
> The reason behind this extension is, that in a multi user scenario, the DB
> may start the transaction too late.
> Scenario:
> 2 threads are reading say a RevisionDescriptor for the same URL nearly in
> the same time frame and thread1 modifies the RD and commits it.  After
this
> thread2 modifies the (read and now out-dated) RD, stores it and tries to
> commit the changes. Depending on the isolation level, the used DB and
their
> transaction implementation, following situations could occur:
> 1) The (out dated) RD is stored and committed in the DB without a problem
> ==> semantical inconsistence (lost update problem)
> 2) The RD can not be stored ==> Exception
> 3) The RD can not be committed ==> Exception
> If the Slide kernel would call the xxxForUpdate methods in case of the
e.g.
> RD wants to be changed in this thread (this has to be implemented yet) the
> stores/DBs could open their transaction a lot earlier and/or depending on
> the used DB/store technology implement their own synchronization/waiting
> mechanism. This would increase through put (thus performance) and reduce
the
> amount of not successful commands. The old retrieveXXX(...) would have the
> semantic read-for-read.
>
> Does this make sense?

Yes, I know about that problem, as the current system definitely allows
dirty reads.
I don't like too much duplicating every retrieve method to do that, however.

Maybe add a startUpdate(String uri) method in the namespace access token,
and in the Store interface (where it would be startUpdate(Uri uri)) ?
Using the method would be optional, but would basically pre-enlist the store
in the transaction, therefore preventing dirty reads if its own isolation
level is high enough.

If you agree with that, I can make the changes.

Remy