You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2005/06/22 08:50:33 UTC
Re-Locking transactionables
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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Re-Locking transactionables
Posted by Doug Chestnut <ch...@apache.org>.
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: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Re-Locking transactionables
Posted by Doug Chestnut <ch...@apache.org>.
>> - Bob locks D again (version 2). (*)
If I understand correctly, the object can only have one lock at a time,
right?
But, the owner of a lock on an object should be able to use [execute
usecases on an object] that object until they checkin the object, right?
The owner of the lock doesn't need to [shouldn't be able to] relock an
object.
Please let me know if this is not the case :)
--Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Re-Locking transactionables
Posted by Andreas Hartmann <an...@apache.org>.
Jann Forrer wrote:
Somehow my messages from yesterday didn't arrive on the list,
so I'll try again :(
[...]
> 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?
In 1.4 there's a difference between locking and check-out. If you use
optimistic offline lock, locked objects can still be changed by other
users. More info:
http://wiki.apache.org/lenya/OverviewRepository
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Re-Locking transactionables
Posted by Jann Forrer <ja...@id.unizh.ch>.
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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org