You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Brian McCallister <mc...@forthillcompany.com> on 2004/04/07 20:04:13 UTC
Fwd: PersistenceBroker.delete() for objects that use optimisitic locking
Forwarding from -users list
Begin forwarded message:
> From: "Andy Malakov" <an...@transdecisions.com>
> Date: April 7, 2004 1:49:19 PM EDT
> To: "OJB Users List" <oj...@db.apache.org>
> Subject: PersistenceBroker.delete() for objects that use optimisitic
> locking
> Reply-To: "OJB Users List" <oj...@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
Re: Fwd: PersistenceBroker.delete() for objects that use optimisitic
locking
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi all,
checked it in.
jakob
Thomas Mahler wrote:
> hi all,
>
>
>
> Armin Waibel wrote:
> <snip>
>
>>
>> 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.
>>
>
> I'm +1 for this solution!
>
> Thomas
>
>
>> 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" <an...@transdecisions.com>
>>>>>>> Date: April 7, 2004 1:49:19 PM EDT
>>>>>>> To: "OJB Users List" <oj...@db.apache.org>
>>>>>>> Subject: PersistenceBroker.delete() for objects that use
>>>>>>> optimisitic locking
>>>>>>> Reply-To: "OJB Users List" <oj...@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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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
Re: Fwd: PersistenceBroker.delete() for objects that use optimisitic
locking
Posted by Thomas Mahler <th...@web.de>.
hi all,
Armin Waibel wrote:
<snip>
>
> 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.
>
I'm +1 for this solution!
Thomas
> 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" <an...@transdecisions.com>
>>>>>> Date: April 7, 2004 1:49:19 PM EDT
>>>>>> To: "OJB Users List" <oj...@db.apache.org>
>>>>>> Subject: PersistenceBroker.delete() for objects that use
>>>>>> optimisitic locking
>>>>>> Reply-To: "OJB Users List" <oj...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: Fwd: PersistenceBroker.delete() for objects that use optimisitic
locking
Posted by Armin Waibel <ar...@apache.org>.
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" <an...@transdecisions.com>
>>>>> Date: April 7, 2004 1:49:19 PM EDT
>>>>> To: "OJB Users List" <oj...@db.apache.org>
>>>>> Subject: PersistenceBroker.delete() for objects that use
>>>>> optimisitic locking
>>>>> Reply-To: "OJB Users List" <oj...@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
Re: Fwd: PersistenceBroker.delete() for objects that use optimisitic
locking
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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 ?
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" <an...@transdecisions.com>
>>>> Date: April 7, 2004 1:49:19 PM EDT
>>>> To: "OJB Users List" <oj...@db.apache.org>
>>>> Subject: PersistenceBroker.delete() for objects that use optimisitic
>>>> locking
>>>> Reply-To: "OJB Users List" <oj...@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
Re: Fwd: PersistenceBroker.delete() for objects that use optimisitic
locking
Posted by Jakob Braeuchi <jb...@gmx.ch>.
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" <an...@transdecisions.com>
>>> Date: April 7, 2004 1:49:19 PM EDT
>>> To: "OJB Users List" <oj...@db.apache.org>
>>> Subject: PersistenceBroker.delete() for objects that use optimisitic
>>> locking
>>> Reply-To: "OJB Users List" <oj...@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
Re: Fwd: PersistenceBroker.delete() for objects that use optimisitic locking
Posted by Andy Malakov <an...@transdecisions.com>.
Hello Armin,
The third option is to document current behavior.
When optimistic locking is not enabled and object is missing from database (e.g. due to cascade delete of another object in the same
transaction),
PB.delete(object) doesn't complain about nothing being deleted.
It seems logical, that the same applies to objects that have optimistic locking enabled.
Thanks a lot,
Andy
> >> 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" <an...@transdecisions.com>
> >> Date: April 7, 2004 1:49:19 PM EDT
> >> To: "OJB Users List" <oj...@db.apache.org>
> >> Subject: PersistenceBroker.delete() for objects that use optimisitic
> >> locking
> >> Reply-To: "OJB Users List" <oj...@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
Re: Fwd: PersistenceBroker.delete() for objects that use optimisitic
locking
Posted by Armin Waibel <ar...@apache.org>.
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" <an...@transdecisions.com>
>> Date: April 7, 2004 1:49:19 PM EDT
>> To: "OJB Users List" <oj...@db.apache.org>
>> Subject: PersistenceBroker.delete() for objects that use optimisitic
>> locking
>> Reply-To: "OJB Users List" <oj...@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