Re: Insert instead of update generated in RC6

[Armin Waibel]

Hi again,

all ejb-example tests pass (odmg- and PB-Tests) on JBoss 3.2.2 and 
MaxDB. Maybe I forget to write a test for object update ;-).

> Does ist help? I can not see your Methods at the stack trace. Is it
> possible, that the cache is never checked?
You can't see one of these methods in your stack trace, bacause these 
methods maybe generate a wrong value for boolean 'doInsert' in your case.
The change made between rc5 to rc6 is a new check
serviceBrokerHelper().hasNullPKField(cld, obj);
and the
deletedDuringTransaction.contains(oid);
check. Is it possible that you pass a nullified PK field (declared in 
decriptor) when you update an object? In that case OJB try to insert the 
object.

I think you have two possibilities:
- remote debugging of this part of PBImpl class to see if a wrong 
boolean value was set - signals insert instead of update.
- Put some System.out.println to check the boolean or/and comment out 
the new stuff and see what's going on.

regards,
Armin
Guido Beutler wrote:

Armin Waibel wrote:

Hi Guido,

Guido Beutler wrote:

Hello,

I updated from RC5 to RC6. I am using OJB inside of JBoss 3.2.3 with 
DB2 V8.
Since update to RC6  OJB generates a insert for every stored object 
when using PB API.
OJB seems not to check if the object exists at database. If the 
object already exist,
a SQL Exception is thrown. (-803 which means dublicated PK). If I try 
to insert the same object
several times, every time the same exception is thrown. If I select 
the object first, OJB generates a insert too.
I tried the same with RC5 (just to be sure that it is not a error at 
the test case) and RC5 works as expected.
If the object exist a update is generated.
Did I miss something or is it a new issue?

hmm, in PBImpl we do:

ClassDescriptor cld = getClassDescriptor(obj.getClass());
/*
if one of the PK fields was null, the objects was new
and needs insert
*/
boolean doInsert = serviceBrokerHelper().hasNullPKField(cld, obj);
//if one of the PK field represents 'null' OJB assume the object is new
Identity oid = new Identity(obj, this, cld);
/*
if the object has been deleted during this transaction,
then we must insert it
*/
boolean shouldRemoveFromDeleted = false;
if (!doInsert)
{
    doInsert = deletedDuringTransaction.contains(oid);
    shouldRemoveFromDeleted = true;
}
/*
if PK values are set, lookup cache or db to see whether object
needs insert or update
*/
if (!doInsert)
{
    doInsert = objectCache.lookup(oid) == null
        && !serviceBrokerHelper().doesExist(cld, oid, obj);
}
// now store it:
store(obj, oid, cld, doInsert);
Which of these methods returns a wrong result?

regards,
Armin
Hi Armin, :-)

that's the stacktrace:

org.apache.ojb.broker.PersistenceBrokerSQLException: SQL failure while 
insert object data for class
...
       at 
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeInsert(JdbcAccessImpl.java:242) 

       at 
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBrokerImpl.java:1620) 

       at 
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:1537) 

       at 
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl.java:683) 

       at 
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:174) 

       at 
org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(DelegatingPersistenceBroker.java:174) 

And here's the Cache related stuff from ojb.properties:

#---------------------------------------------------------------------------------------- 

# Object cache
#---------------------------------------------------------------------------------------- 

# The ObjectCacheClass entry tells OJB which concrete ObjectCache
# implementation is to be used as standard cache.
# Its also possible to override this entry adding object-cache elements
# on jdbc-connection-descriptor level and
# per class-descriptor in repository file. More info see documentation.
#
ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheEmptyImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheJCSPerClassImpl
#ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCachePerClassImpl
#
#
# This property is only relevant if the per class-descriptor object-cache
# declaration was used in conjunction with metadata runtime changes.
# If set 'flase' the class name of the object is used
# to find a per class ObjectCache implementation.
# If set 'true' the ObjectCacheDescriptor instance is used as key to
# find a per class ObjectCache, this enables to use different ObjectCache
# instances for the same class.
descriptorBasedCaches=false
#
#
# Use CacheFilters to do filter operations before caching methods were
# called. Build your own filter class by implementing 
org.apache.ojb.cache.CacheFilter.
# It is possible to use a arbitrary number of CacheFilters, but this slows
# down the performance of the cache, thus handle with care.
#
# - org.apache.ojb.broker.cache.CacheFilterClassImpl
# allows filtering of classes
# - org.apache.ojb.broker.cache.CacheFilterPackageImpl
# allows filtering of packages
# More info see Javadoc of the according classes.
# Set a comma separated list of CacheFilter.
#ObjectCacheFilter=org.apache.ojb.broker.cache.CacheFilterClassImpl,org.apache.ojb.broker.cache.CacheFilterPackageImpl 

#

Does ist help? I can not see your Methods at the stack trace. Is it 
possible, that the cache is never checked?

best regards,

Guido

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]