db-ojb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert S. Sfeir" <rob...@codepuccino.com>
Subject Re: cvs commit: db-ojb/src/java/org/apache/ojb/broker/accesslayer JdbcAccessImpl.java
Date Sat, 13 Dec 2003 19:16:23 GMT
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

Mime
View raw message