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 "Robert S. Sfeir" <ro...@codepuccino.com> on 2003/12/13 20:16:23 UTC
Re: cvs commit: db-ojb/src/java/org/apache/ojb/broker/accesslayer
JdbcAccessImpl.java
Thomas,
On the JDBCAccessImpl, I think it would be a good idea to throw the
exception. We should make it so the message can be easily parsable, so
someone could catch it in their app and deal with it appropriately as
they wish. Perhaps an OJB error number like OJB123: Error text here. I
think we should be using more and more specific OJB error numbers so
people can rely on them, much like in Oracle, and handle them.
I would be glad to go through the code and add these error numbers to
various exceptions, we'd need to agree on a number format, and perhaps
meaning. Maybe this is not a 1.0 thing (I think it can be).
Just my 2cents.
R
On Sat, 2003-12-13 at 13:57, thma@apache.org wrote:
> thma 2003/12/13 10:57:19
>
> Modified: src/test/org/apache/ojb/broker OptimisticLockingTest.java
> src/java/org/apache/ojb/broker/accesslayer
> JdbcAccessImpl.java
> Log:
> fix OptimisticLocking problems on delete.
> Maybe my fix needs some more discussions,
> please have a look at my comments
>
> Revision Changes Path
> 1.8 +0 -4 db-ojb/src/test/org/apache/ojb/broker/OptimisticLockingTest.java
>
> Index: OptimisticLockingTest.java
> ===================================================================
> RCS file: /home/cvs/db-ojb/src/test/org/apache/ojb/broker/OptimisticLockingTest.java,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -u -r1.7 -r1.8
> --- OptimisticLockingTest.java 9 Dec 2003 13:46:46 -0000 1.7
> +++ OptimisticLockingTest.java 13 Dec 2003 18:57:18 -0000 1.8
> @@ -182,10 +182,6 @@
> broker.delete(copy1);
> broker.commitTransaction();
>
> - /*
> - TODO: second call will cause an optimistic locking exception,
> - how can we avoid this?
> - */
> try
> {
> broker.beginTransaction();
>
>
>
> 1.17 +7 -2 db-ojb/src/java/org/apache/ojb/broker/accesslayer/JdbcAccessImpl.java
>
> Index: JdbcAccessImpl.java
> ===================================================================
> RCS file: /home/cvs/db-ojb/src/java/org/apache/ojb/broker/accesslayer/JdbcAccessImpl.java,v
> retrieving revision 1.16
> retrieving revision 1.17
> diff -u -r1.16 -r1.17
> --- JdbcAccessImpl.java 9 Dec 2003 17:19:59 -0000 1.16
> +++ JdbcAccessImpl.java 13 Dec 2003 18:57:18 -0000 1.17
> @@ -130,9 +130,14 @@
> broker.serviceStatementManager().bindDelete(stmt, cld, obj);
> if (logger.isDebugEnabled())
> logger.debug("executeDelete: " + stmt);
> +
> + // @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);
> + //throw new OptimisticLockException("Object has been modified by someone else", obj);
> }
>
> // Harvest any return values.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
--
Robert S. Sfeir
robert@codepuccino.com
"A bug is an out-of-scope feature!" -- Sfeir
Re: cvs commit: db-ojb/src/java/org/apache/ojb/broker/accesslayer
JdbcAccessImpl.java
Posted by Thomas Mahler <th...@web.de>.
Hi again Robert,
Robert S. Sfeir wrote:
> Thomas,
>
> On the JDBCAccessImpl, I think it would be a good idea to throw the
> exception. We should make it so the message can be easily parsable, so
> someone could catch it in their app and deal with it appropriately as
> they wish. Perhaps an OJB error number like OJB123: Error text here. I
> think we should be using more and more specific OJB error numbers so
> people can rely on them, much like in Oracle, and handle them.
Mhh, I think it would be OK to throw a Persistencebroker exception
"Delete Query affected 0 rows. Either the record was already deleted or
was modified by someone else"
But it's not OK to throw an OL exception here.
> I would be glad to go through the code and add these error numbers to
> various exceptions, we'd need to agree on a number format, and perhaps
> meaning. Maybe this is not a 1.0 thing (I think it can be).
>
The idea is good in principle. But I don't see it as an option for 1.0.
RC5 is finished tonight.
if there are no major bugs RC5 will be relabeled as 1.0 within 2 weeks.
so I think it's more an 1.1 issue...
cheers,
Thomas
> Just my 2cents.
>
> R
>
> On Sat, 2003-12-13 at 13:57, thma@apache.org wrote:
>
>>/thma 2003/12/13 10:57:19
>>
>> Modified: src/test/org/apache/ojb/broker OptimisticLockingTest.java
>> src/java/org/apache/ojb/broker/accesslayer
>> JdbcAccessImpl.java
>> Log:
>> fix OptimisticLocking problems on delete.
>> Maybe my fix needs some more discussions,
>> please have a look at my comments
>>
>> Revision Changes Path
>> 1.8 +0 -4 db-ojb/src/test/org/apache/ojb/broker/OptimisticLockingTest.java
>>
>> Index: OptimisticLockingTest.java
>> ===================================================================
>> RCS file: /home/cvs/db-ojb/src/test/org/apache/ojb/broker/OptimisticLockingTest.java,v
>> retrieving revision 1.7
>> retrieving revision 1.8
>> diff -u -r1.7 -r1.8
>> --- OptimisticLockingTest.java 9 Dec 2003 13:46:46 -0000 1.7
>> +++ OptimisticLockingTest.java 13 Dec 2003 18:57:18 -0000 1.8
>> @@ -182,10 +182,6 @@
>> broker.delete(copy1);
>> broker.commitTransaction();
>>
>> - /*
>> - TODO: second call will cause an optimistic locking exception,
>> - how can we avoid this?
>> - */
>> try
>> {
>> broker.beginTransaction();
>>
>>
>>
>> 1.17 +7 -2 db-ojb/src/java/org/apache/ojb/broker/accesslayer/JdbcAccessImpl.java
>>
>> Index: JdbcAccessImpl.java
>> ===================================================================
>> RCS file: /home/cvs/db-ojb/src/java/org/apache/ojb/broker/accesslayer/JdbcAccessImpl.java,v
>> retrieving revision 1.16
>> retrieving revision 1.17
>> diff -u -r1.16 -r1.17
>> --- JdbcAccessImpl.java 9 Dec 2003 17:19:59 -0000 1.16
>> +++ JdbcAccessImpl.java 13 Dec 2003 18:57:18 -0000 1.17
>> @@ -130,9 +130,14 @@
>> broker.serviceStatementManager().bindDelete(stmt, cld, obj);
>> if (logger.isDebugEnabled())
>> logger.debug("executeDelete: " + stmt);
>> +
>> + // @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);
>> + //throw new OptimisticLockException("Object has been modified by someone else", obj);
>> }
>>
>> // Harvest any return values.
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>>For additional commands, e-mail: //ojb-dev-help@db.apache.org <ma...@db.apache.org>/
>>
> --
> Robert S. Sfeir
> robert@codepuccino.com
> "A bug is an out-of-scope feature!" -- Sfeir
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org