Hi Andreas, Didn't know about this issue, thanks for spotting it :).
So, we remove canCheckOut and create a boolean isCheckedOut(String userid) method? It would return if the object has a lock owned by the current user? Or should I be using the RCMLEntry to get the owner of a lock?
Thanks, --Doug 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. - 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. The check-out problem still remains, but we'll certainly find a solution. WDYT? -- Andreas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
