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 Thu, 08 Apr 2004 00:25:10 GMT
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


Mime
View raw message