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
