db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Armin Waibel <arm...@apache.org>
Subject Re: Fwd: PersistenceBroker.delete() for objects that use optimisitic locking
Date Wed, 21 Apr 2004 21:32:41 GMT
Hi all,

Jakob Braeuchi wrote:
> hi brian, armin, thomas
> 
> i admit that we can not distinguish whether the object has been deleted 
> before or has been modified. but i think in either case we should inform 
> the user by throwing an OptimisticLockException.
> 
> as an alternative we could do the following:
> 
> 1.) execute a delete with the locking attributes
> 2.) check if the rowcount is 0
> 3.) select the object by pk (no locking attributes)
> 4.) if the object is not found, then it has been deleted by someone 
> else, no OptimisticLockException is thrown
> 5.) if the object is found, then it has been modified by someone else 
> and an OptimisticLockException is thrown
> 
> this scenario is more complicated than the one we have currently 
> implemented and i'm not sure if it's really necessary.
> 
> btw. we could always do a select first before doing an update ore delete 
> when optimistic locking is enabled. what do you think about ?
>

I agree with your first suggestion only to throw the 
OptimisticLockException. Optimistic locking should inform the user about 
concurrent modification action and it doesn't matter (in my opinion ;-)) 
whether it is a concurrent update or delete operation. We can modify the 
error message and specify both reasons for the exception. It's no 
problem for the user to detect the reason for the exception.

regards,
Armin

> jakob
> 
> 
> Jakob Braeuchi wrote:
> 
>> hi brian, armin,
>>
>> +1 for throwing the exception
>>
>> jakob
>>
>> Armin Waibel wrote:
>>
>>> Hi,
>>>
>>>  >> If optimistic locking is enabled for some object class,
>>>  >> PersistenceBroker.delete (object) cannot delete the object if it has
>>>  >> been modified by another session. In current CVS version, delete
>>>  >> statement generated for PB.delete() will be simply ignored (!). One
>>>  >> have to use PB.deleteByQuery(...) for delete that bypasses stale
>>>  >> object check.
>>>  >>
>>>
>>> I think this is a strong argument to enable the exception to inform 
>>> the user that the delete was not successful and the row still exists 
>>> in DB. Then the user can refresh the object and try to delete again.
>>>
>>> Or the SqlGenerator implementation should never include the locking 
>>> field in the delete where-clause.
>>>
>>> I would prefer the first solution, because this solution let the user 
>>> decide what to do and avoid "dirty deletes".
>>>
>>> regards,
>>> Armin
>>>
>>> Brian McCallister wrote:
>>>
>>>> Forwarding from -users list
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: "Andy Malakov" <andy@transdecisions.com>
>>>>> Date: April 7, 2004 1:49:19 PM EDT
>>>>> To: "OJB Users List" <ojb-user@db.apache.org>
>>>>> Subject: PersistenceBroker.delete() for objects that use 
>>>>> optimisitic locking
>>>>> Reply-To: "OJB Users List" <ojb-user@db.apache.org>
>>>>>
>>>>> Hello All,
>>>>>
>>>>> It would be nice if sometime before 1.0 the following issue will be 
>>>>> clarified or documented.
>>>>>
>>>>> If optimistic locking is enabled for some object class, 
>>>>> PersistenceBroker.delete (object) cannot delete the object if it 
>>>>> has been modified by another session. In current CVS version, 
>>>>> delete statement generated for PB.delete() will be simply ignored 
>>>>> (!). One have to use PB.deleteByQuery(...) for delete that bypasses 
>>>>> stale object check.
>>>>>
>>>>> Before RC5 this situation was producing OptimisticLockException 
>>>>> exception ("Object has been modified by someone else"). But in Dec 
>>>>> 2003 Thomas commented it out:
>>>>>
>>>>> File: o.a.ojb.broker.accesslayer.JdbcAccessImpl.java (line 134):
>>>>>
>>>>> // @todo: clearify semantics
>>>>> // thma: the following check is not secure. The object could be 
>>>>> deleted *or* changed.
>>>>> // if it was deleted it makes no sense to throw an OL exception.
>>>>> // does is make sense to throw an OL exception if the object was 
>>>>> changed?
>>>>> if (stmt.executeUpdate() == 0 && cld.isLocking()) //BRJ
>>>>> {
>>>>>  //throw new OptimisticLockException("Object has been modified by 
>>>>> someone else", obj);
>>>>> }
>>>>>
>>>>> Thanks,
>>>>> Andy
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org


Mime
View raw message