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 Ron Gallagher <rg...@bellsouth.net> on 2003/02/18 01:41:47 UTC

Bug in PersistenceBrokerImpl::storeToDb()

I have found what I believe is a bug in how PersistenceBrokerImpl stores objects in the cache.  In our environment, we're using Oracle packages to handle all persistence operations.  The "ADD" function is structured to assign any primary key values and return the newly assigned values back to the caller.  We've got all of this working via custom extensions to various components, including JdbcAccess.

Here's the problem.  Prior to the execution of storeToDb routine, an Identity is constructed using the original primary key values.  In our case, these values for a new object will always be 0.  The construction of the Identity occurs in store(Object,ObjectModification).  When execution gets to the storeToDb method, the Identity that was constructed using the 'original' primary key values is used to place the newly stored object in the cache.  The problem for us is that during storage (dbAccess.executeInsert(cld, obj);), our extension to JdbcAccess updates the primary key value in "obj" with the value that was returned by the corresponding Oracle package.  When "obj" is placed in the cache, it needs to be identified using the new value(s) for the primary key.

The change is to simply construct an Identity using the current primary key values from "obj".  I've attached a file containing this change.

Ron Gallagher
Atlanta, GA
rongallagher@bellsouth.net

Re: Bug in PersistenceBrokerImpl::storeToDb()

Posted by Thomas Mahler <th...@web.de>.
Hi again Ron,

i just committed your patch to cvs. Thanks,
Thomas

Ron Gallagher wrote:
 > I have found what I believe is a bug in how PersistenceBrokerImpl
 > stores objects in the cache.  In our environment, we're using Oracle
 > packages to handle all persistence operations.  The "ADD" function is
 > structured to assign any primary key values and return the newly
 > assigned values back to the caller.  We've got all of this working
 > via custom extensions to various components, including JdbcAccess.
 >
 > Here's the problem.  Prior to the execution of storeToDb routine, an
 > Identity is constructed using the original primary key values.  In
 > our case, these values for a new object will always be 0.  The
 > construction of the Identity occurs in
 > store(Object,ObjectModification).  When execution gets to the
 > storeToDb method, the Identity that was constructed using the
 > 'original' primary key values is used to place the newly stored
 > object in the cache.  The problem for us is that during storage
 > (dbAccess.executeInsert(cld, obj);), our extension to JdbcAccess
 > updates the primary key value in "obj" with the value that was
 > returned by the corresponding Oracle package.  When "obj" is placed
 > in the cache, it needs to be identified using the new value(s) for
 > the primary key.
 >
 > The change is to simply construct an Identity using the current
 > primary key values from "obj".  I've attached a file containing this
 > change.
 >
 > Ron Gallagher Atlanta, GA rongallagher@bellsouth.net
 >
 >
 > ------------------------------------------------------------------------
 >
 >
 > RCS file:
 > /home/cvspublic/db-ojb/src/java/org/apache/ojb/broker/singlevm/Persis-
 > tenceBrokerImpl.java,v retrieving revision 1.130 diff -r1.130
 > PersistenceBrokerImpl.java 1817c1817,1822 <
 > objectCache.cache(oid, obj); ---
 >
 >> // Create a new Identity based on the current set of primary key
 >> values. Identity newOid = new Identity(obj, this, cld);
 >>
 >> // Add the object to the cache. objectCache.cache(newOid, obj);
 >
 >
 > *****CVS exited normally with code 1*****
 >
 >
 >
 >
 > ------------------------------------------------------------------------
 >
 >
 > ---------------------------------------------------------------------
 >  To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org For
 > additional commands, e-mail: ojb-dev-help@db.apache.org