> 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
