Hello Remy,
Sounds good.
The Slide kernel would call the startUpdate method for every URL, the kernel
is going to modify, before reading, isn't it? Would you plan to have the
startUpdate implemented in every child store?
Juergen
-----Original Message-----
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 28, 2001 17.15 PM
To: [EMAIL PROTECTED]
Subject: Re: multi user store enhancement
> 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
