On 19 Nov 2003, at 05:03, Oliver Zeigermann wrote:
Hi Stefano,
I am wondering why you check for any lock for the source uri. Also, why no lock for the destination? Why is there no patch for the copy method?
Could you please explain a little bit more?!
Glad you asked ;-)
That bug is *really* subdle and was hard to find. It is basically triggered by the fact that the "move" operation performed between two different stores is not atomic, but it done as "copy" then "delete". But "copy" doesn't (nor should, IMHO) check for the lock of the source uri, but "delete" obviously does. This transforms the "move" of a locked resource a "copy", which is wrong (the litmus tests fail for this reason).
Hmmm. Do not understand... Aren't you mixing up isolation of a transaction with general locking? There are those locks set externally spanning multiple requests and there *might* be internal locks guaranteeing correctness of single requests.
I choose to fix it by checking for the lock on the source URI right away to avoid even trying to do the move if the source URI is locked. This solves the issue cleanly and it's store independent.
Hmmm, wondering where this is done for the Delete method, really could not find it. I still think the more appropriate place for this check should be MacroImpl to use this functionality from other tiers as well.
As for copy, it is not illegal to copy a locked resource so I didn't check for it.
I see.
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
