Andreas Hartmann wrote:
Hi Lenya devs,
the addition of the canCheckOut() method to Versionable
which allows subsequent locking by the same user pointed me to a
flaw in the transaction design - thanks Doug :)
I'm afraid there are some problems (they existed before
the change too). Imagine the following situation:
- Bob starts a usecase which involves Document D.
- Bob locks D (version 1).
- Bob does some changes on D.
- Alice starts a usecase which involves D.
- Alice changes D (version 1 -> version 2).
- Alice commits her usecase.
- D is saved to version 2.
I am not too familiar with the locking mechanism in 1.4 ant the
following is probably a dumb questino but why is Alice
able to change D if Bob locks it?
- Bob locks D again (version 2). (*)
- Bob changes D (version 1 -> Version 3).
- D is saved to version 3. This is possible since the lock
for version 2 is still valid.
Line (*) creates a lock which points to the state after Alice's
changes. This means that we have a inconsistent state: Bob
works with the document version 1, but the lock points to
version 2. When Bob commits his transaction, Alice's changes
will go unnoticed and they will get lost!
So, instead of re-locking a versionable we have to check if it
is already locked and don't lock it again. Subsequent locking
in a single usecase must be avoided.
+1
The check-out problem still remains, but we'll certainly
find a solution.
Why not check whether the user A which checked-out a Document has still
a valid session. If yes user B should not be allowed to check out the
document. If not inform user B but let him check out the Document.
Jann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
