You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by Gus Heck <gu...@olin.edu> on 2004/02/19 23:31:38 UTC
Re: Problems with JDO cache (more info)
I found a related post from last year....
http://www.mail-archive.com/ojb-user@db.apache.org/msg00856.html
But I don't seem to see the constructor suggested therein (single arg)
anymore, or maybe I am looking in the wrong place... The only Identity I
can find is o.a.o.broker.Identity but now the constructors all require
the PB or this one:
new Identity(PersonBase.class, PersonBase.class, new Object[]
{data.getId()});
I tried adding that in as suggested in the post like this:
private void aquireUniqueID() {
txState.beginTx();
data.setId(this.idMgr.assignNextId());
new Identity(PersonBase.class, PersonBase.class, new Object[]
{data.getId()});
try {
txState.getPM().evictAll();
txState.getPM().makePersistent(data);
} catch (JDOUserException jdoue) {
System.out.println(jdoue);
throw new RuntimeException(jdoue);
}
txState.commitTx();
But I still get the same thing....
-Gus
Gus Heck wrote:
> I'm getting this exception:
>
> Object exists. Instance with the same primary key is already in the
> PersistenceManager cache.
> javax.jdo.JDOUserException: Object exists. Instance with the same
> primary key is already in the PersistenceManager cache.
> at com.sun.jdori.common.CacheManagerImpl.register(Unknown Source)
> at com.sun.jdori.common.PersistenceManagerImpl.register(Unknown
> Source)
> at
> com.sun.jdori.common.state.StateManagerImpl.initializeSM(Unknown Source)
> at
> com.sun.jdori.common.state.StateManagerImpl.makeAutoPersistent(Unknown
> Source)
> at
> com.sun.jdori.common.state.ReachabilityHandler$AutoPersistentProcessor.process(Unknown
> Source)
> at
> com.sun.jdori.common.state.ReachabilityHandler$AutoPersistentProcessor.processArray(Unknown
> Source)
> at
> com.sun.jdori.common.state.ReachabilityHandler$AutoPersistentProcessor.process(Unknown
> Source)
> at
> com.sun.jdori.common.state.ReachabilityHandler.process(Unknown Source)
> at
> com.sun.jdori.common.state.StateManagerImpl.processReachability(Unknown
> Source)
> at
> com.sun.jdori.common.state.StateManagerImpl.makePersistent(Unknown
> Source)
> at com.sun.jdori.common.CacheManagerImpl.makePersistent(Unknown
> Source)
> at
> com.sun.jdori.common.PersistenceManagerImpl.makePersistentInternal(Unknown
> Source)
> at
> com.sun.jdori.common.PersistenceManagerImpl.makePersistent(Unknown
> Source)
> at
> com.sun.jdori.common.PersistenceManagerWrapper.makePersistent(Unknown
> Source)
> at
> org.cs101.fdb.impl.jdo.PersonImpl.aquireUniqueID(PersonImpl.java:114)
> at org.cs101.fdb.impl.jdo.PersonImpl.store(PersonImpl.java:156)
> at org.cs101.fdb.test.PersonTest.storePerson(PersonTest.java:140)
> at org.cs101.fdb.test.PersonTest.testStore(PersonTest.java:150)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
>
> from this:
>
> // set the primary key Id number ... just an Integer, small DB,
> nothing special, no extents needed.
> data.setId(idMgr.assignNextId());
>
> try {
> txState.getPM().evictAll();
> System.out.println(txState.getPM().getObjectId(data)); //
> prints null
> System.out.println("persistent:"
> +JDOHelper.isPersistent(data)); // prints false
> System.out.println("transactional:"
> +JDOHelper.isTransactional(data)); // prints false
> System.out.println("toid:"
> +JDOHelper.getTransactionalObjectId(data)); // prints null
>
> txState.getPM().makePersistent(data); // causes exception
>
> } catch (JDOUserException jdoue) {
> System.out.println(jdoue);
> //System.exit(1); // if I uncomment this all database
> tables are empty
> // so there is nothing in
> the database to conflict.
> throw new RuntimeException(jdoue);
> }
> This is really annoying because it doesn't say what object
> already exists... the failing object is not being set (I get null back
> when I invoke getFailedObject() on the exception. I implemented
> InstanceCallbacks jdoPreStore on every single persistant class I have
> and made them all print something unique, and apparently this error is
> occuring before any instance of any persistent class is stored because
> nothing is printed. (unless something is sneaking in without instance
> callbacks). Alternately, things are getting cached before I make them
> persistent which seems wrong. If I ignore this exception by catching
> it, commit gives me messages about SQL errors because PERSON_ID in my
> indirection table is not allowed to be null. It would seem that an
> instance with id=null is getting cached and then re-cached before any
> jdoPreStore calls are made. The null may be because the makePersistent
> failed though.
>
> Anyone seen anything like this. The only thing special about this
> class relative to the others is that I am trying to implement a
> collection on it. I am implementing it as m:n relationship with an
> indirection table and using @ojb.collection foreignkey and
> remote-foreignkey xdoclet tags.
>
> Anyone have a clue what my problem is? I'm lost...
>
> -Gus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Problems with JDO cache (solved, sort of)
Posted by Gus Heck <gu...@olin.edu>.
This strategy has worked but only after I took to caching
PersistenceManagers on a per-thread basis, hopefully this won't bite me
later... I almost turned it into a single PM for the whole app but that
seems too extreme. If I don't do this I keep getting JDOUser Exceptions
about Object beloging to another PM or invalid attempt to make
persistent an object that belongs to another PM... etc. We shall see
what happens when I get around to trying to thread test things...
I also found some problems with my xdoclet markup where I had 2
collections and the javadocs were switched due to a cut-paste error... I
don't see why this didn't cause a more obvious problem, since it meant
that the object type for the collection was wrong among other things.
Does OJB check anywhere that the objects going into the collection
actually are the type specified?
If the JDORI would just set the failed object on their exceptions I
might not need to do this since I could possibly grab the PM off the
failed object and try again, but as far as I can tell
JDOUserException.getFailedObject() always reuturns null.
-Gus
Gus Heck wrote:
> I'm getting the impression noone is reading this thread but me, but
> for the sake of anyone who searches later, I have determined the
> following:
>
> the JDORI puts objects in the cache, before calling jdoPreStore. Since
> o.a.o.broker.Identity reflects out the values of the Primary keys
> during addition to the cache, (as best I can tell by stepping through
> with a debugger, Identity creation is the only significant place the
> jdori is invoking ojb code between makePersistent and the exception)
> it appears that objects are getting put in with null pk values... so
> my attempt to fix this with Persistence call backs is doomed. That
> seems like a problem in the jdori, so I am going to try to work around
> it by taking extra measures to ensure that the Id gets assigned before
> makePersistent is called. I'll post if I make it work or find anything
> else interesting.
>
> -Gus
>
> Gus Heck wrote:
>
>> I found a related post from last year....
>>
>> http://www.mail-archive.com/ojb-user@db.apache.org/msg00856.html
>>
>> But I don't seem to see the constructor suggested therein (single
>> arg) anymore, or maybe I am looking in the wrong place... The only
>> Identity I can find is o.a.o.broker.Identity but now the constructors
>> all require the PB or this one:
>>
>> new Identity(PersonBase.class, PersonBase.class, new Object[]
>> {data.getId()});
>>
>> I tried adding that in as suggested in the post like this:
>>
>>
>> private void aquireUniqueID() {
>> txState.beginTx();
>> data.setId(this.idMgr.assignNextId());
>> new Identity(PersonBase.class, PersonBase.class, new Object[]
>> {data.getId()});
>> try {
>> txState.getPM().evictAll();
>> txState.getPM().makePersistent(data);
>> } catch (JDOUserException jdoue) {
>> System.out.println(jdoue);
>> throw new RuntimeException(jdoue);
>> }
>> txState.commitTx();
>>
>> But I still get the same thing....
>>
>> -Gus
>>
>> Gus Heck wrote:
>>
>>> I'm getting this exception:
>>>
>>> Object exists. Instance with the same primary key is already in the
>>> PersistenceManager cache.
>>> javax.jdo.JDOUserException: Object exists. Instance with the same
>>> primary key is already in the PersistenceManager cache.
>>> at com.sun.jdori.common.CacheManagerImpl.register(Unknown Source)
>>> at
>>> com.sun.jdori.common.PersistenceManagerImpl.register(Unknown Source)
>>> at
>>> com.sun.jdori.common.state.StateManagerImpl.initializeSM(Unknown
>>> Source)
>>> at
>>> com.sun.jdori.common.state.StateManagerImpl.makeAutoPersistent(Unknown
>>> Source)
>>> at
>>> com.sun.jdori.common.state.ReachabilityHandler$AutoPersistentProcessor.process(Unknown
>>> Source)
>>> at
>>> com.sun.jdori.common.state.ReachabilityHandler$AutoPersistentProcessor.processArray(Unknown
>>> Source)
>>> at
>>> com.sun.jdori.common.state.ReachabilityHandler$AutoPersistentProcessor.process(Unknown
>>> Source)
>>> at
>>> com.sun.jdori.common.state.ReachabilityHandler.process(Unknown Source)
>>> at
>>> com.sun.jdori.common.state.StateManagerImpl.processReachability(Unknown
>>> Source)
>>> at
>>> com.sun.jdori.common.state.StateManagerImpl.makePersistent(Unknown
>>> Source)
>>> at
>>> com.sun.jdori.common.CacheManagerImpl.makePersistent(Unknown Source)
>>> at
>>> com.sun.jdori.common.PersistenceManagerImpl.makePersistentInternal(Unknown
>>> Source)
>>> at
>>> com.sun.jdori.common.PersistenceManagerImpl.makePersistent(Unknown
>>> Source)
>>> at
>>> com.sun.jdori.common.PersistenceManagerWrapper.makePersistent(Unknown
>>> Source)
>>> at
>>> org.cs101.fdb.impl.jdo.PersonImpl.aquireUniqueID(PersonImpl.java:114)
>>> at org.cs101.fdb.impl.jdo.PersonImpl.store(PersonImpl.java:156)
>>> at org.cs101.fdb.test.PersonTest.storePerson(PersonTest.java:140)
>>> at org.cs101.fdb.test.PersonTest.testStore(PersonTest.java:150)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>>
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>>
>>>
>>> from this:
>>>
>>> // set the primary key Id number ... just an Integer, small
>>> DB, nothing special, no extents needed.
>>> data.setId(idMgr.assignNextId());
>>>
>>> try {
>>> txState.getPM().evictAll();
>>> System.out.println(txState.getPM().getObjectId(data)); //
>>> prints null
>>> System.out.println("persistent:"
>>> +JDOHelper.isPersistent(data)); // prints false
>>> System.out.println("transactional:"
>>> +JDOHelper.isTransactional(data)); // prints false
>>> System.out.println("toid:"
>>> +JDOHelper.getTransactionalObjectId(data)); // prints null
>>>
>>> txState.getPM().makePersistent(data); // causes exception
>>>
>>> } catch (JDOUserException jdoue) {
>>> System.out.println(jdoue);
>>> //System.exit(1); // if I uncomment this all
>>> database tables are empty
>>> // so there is nothing
>>> in the database to conflict.
>>> throw new RuntimeException(jdoue);
>>> }
>>> This is really annoying because it doesn't say what object
>>> already exists... the failing object is not being set (I get null
>>> back when I invoke getFailedObject() on the exception. I implemented
>>> InstanceCallbacks jdoPreStore on every single persistant class I
>>> have and made them all print something unique, and apparently this
>>> error is occuring before any instance of any persistent class is
>>> stored because nothing is printed. (unless something is sneaking in
>>> without instance callbacks). Alternately, things are getting cached
>>> before I make them persistent which seems wrong. If I ignore this
>>> exception by catching it, commit gives me messages about SQL errors
>>> because PERSON_ID in my indirection table is not allowed to be null.
>>> It would seem that an instance with id=null is getting cached and
>>> then re-cached before any jdoPreStore calls are made. The null may
>>> be because the makePersistent failed though.
>>>
>>> Anyone seen anything like this. The only thing special about this
>>> class relative to the others is that I am trying to implement a
>>> collection on it. I am implementing it as m:n relationship with an
>>> indirection table and using @ojb.collection foreignkey and
>>> remote-foreignkey xdoclet tags.
>>>
>>> Anyone have a clue what my problem is? I'm lost...
>>>
>>> -Gus
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Problems with JDO cache (more info)
Posted by Gus Heck <gu...@olin.edu>.
I'm getting the impression noone is reading this thread but me, but for
the sake of anyone who searches later, I have determined the following:
the JDORI puts objects in the cache, before calling jdoPreStore. Since
o.a.o.broker.Identity reflects out the values of the Primary keys during
addition to the cache, (as best I can tell by stepping through with a
debugger, Identity creation is the only significant place the jdori is
invoking ojb code between makePersistent and the exception) it appears
that objects are getting put in with null pk values... so my attempt to
fix this with Persistence call backs is doomed. That seems like a
problem in the jdori, so I am going to try to work around it by taking
extra measures to ensure that the Id gets assigned before makePersistent
is called. I'll post if I make it work or find anything else interesting.
-Gus
Gus Heck wrote:
> I found a related post from last year....
>
> http://www.mail-archive.com/ojb-user@db.apache.org/msg00856.html
>
> But I don't seem to see the constructor suggested therein (single arg)
> anymore, or maybe I am looking in the wrong place... The only Identity
> I can find is o.a.o.broker.Identity but now the constructors all
> require the PB or this one:
>
> new Identity(PersonBase.class, PersonBase.class, new Object[]
> {data.getId()});
>
> I tried adding that in as suggested in the post like this:
>
>
> private void aquireUniqueID() {
> txState.beginTx();
> data.setId(this.idMgr.assignNextId());
> new Identity(PersonBase.class, PersonBase.class, new Object[]
> {data.getId()});
> try {
> txState.getPM().evictAll();
> txState.getPM().makePersistent(data);
> } catch (JDOUserException jdoue) {
> System.out.println(jdoue);
> throw new RuntimeException(jdoue);
> }
> txState.commitTx();
>
> But I still get the same thing....
>
> -Gus
>
> Gus Heck wrote:
>
>> I'm getting this exception:
>>
>> Object exists. Instance with the same primary key is already in the
>> PersistenceManager cache.
>> javax.jdo.JDOUserException: Object exists. Instance with the same
>> primary key is already in the PersistenceManager cache.
>> at com.sun.jdori.common.CacheManagerImpl.register(Unknown Source)
>> at com.sun.jdori.common.PersistenceManagerImpl.register(Unknown
>> Source)
>> at
>> com.sun.jdori.common.state.StateManagerImpl.initializeSM(Unknown Source)
>> at
>> com.sun.jdori.common.state.StateManagerImpl.makeAutoPersistent(Unknown
>> Source)
>> at
>> com.sun.jdori.common.state.ReachabilityHandler$AutoPersistentProcessor.process(Unknown
>> Source)
>> at
>> com.sun.jdori.common.state.ReachabilityHandler$AutoPersistentProcessor.processArray(Unknown
>> Source)
>> at
>> com.sun.jdori.common.state.ReachabilityHandler$AutoPersistentProcessor.process(Unknown
>> Source)
>> at
>> com.sun.jdori.common.state.ReachabilityHandler.process(Unknown Source)
>> at
>> com.sun.jdori.common.state.StateManagerImpl.processReachability(Unknown
>> Source)
>> at
>> com.sun.jdori.common.state.StateManagerImpl.makePersistent(Unknown
>> Source)
>> at com.sun.jdori.common.CacheManagerImpl.makePersistent(Unknown
>> Source)
>> at
>> com.sun.jdori.common.PersistenceManagerImpl.makePersistentInternal(Unknown
>> Source)
>> at
>> com.sun.jdori.common.PersistenceManagerImpl.makePersistent(Unknown
>> Source)
>> at
>> com.sun.jdori.common.PersistenceManagerWrapper.makePersistent(Unknown
>> Source)
>> at
>> org.cs101.fdb.impl.jdo.PersonImpl.aquireUniqueID(PersonImpl.java:114)
>> at org.cs101.fdb.impl.jdo.PersonImpl.store(PersonImpl.java:156)
>> at org.cs101.fdb.test.PersonTest.storePerson(PersonTest.java:140)
>> at org.cs101.fdb.test.PersonTest.testStore(PersonTest.java:150)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>
>>
>> from this:
>>
>> // set the primary key Id number ... just an Integer, small DB,
>> nothing special, no extents needed.
>> data.setId(idMgr.assignNextId());
>>
>> try {
>> txState.getPM().evictAll();
>> System.out.println(txState.getPM().getObjectId(data)); //
>> prints null
>> System.out.println("persistent:"
>> +JDOHelper.isPersistent(data)); // prints false
>> System.out.println("transactional:"
>> +JDOHelper.isTransactional(data)); // prints false
>> System.out.println("toid:"
>> +JDOHelper.getTransactionalObjectId(data)); // prints null
>>
>> txState.getPM().makePersistent(data); // causes exception
>>
>> } catch (JDOUserException jdoue) {
>> System.out.println(jdoue);
>> //System.exit(1); // if I uncomment this all database
>> tables are empty
>> // so there is nothing in
>> the database to conflict.
>> throw new RuntimeException(jdoue);
>> }
>> This is really annoying because it doesn't say what object
>> already exists... the failing object is not being set (I get null
>> back when I invoke getFailedObject() on the exception. I implemented
>> InstanceCallbacks jdoPreStore on every single persistant class I have
>> and made them all print something unique, and apparently this error
>> is occuring before any instance of any persistent class is stored
>> because nothing is printed. (unless something is sneaking in without
>> instance callbacks). Alternately, things are getting cached before I
>> make them persistent which seems wrong. If I ignore this exception by
>> catching it, commit gives me messages about SQL errors because
>> PERSON_ID in my indirection table is not allowed to be null. It would
>> seem that an instance with id=null is getting cached and then
>> re-cached before any jdoPreStore calls are made. The null may be
>> because the makePersistent failed though.
>>
>> Anyone seen anything like this. The only thing special about this
>> class relative to the others is that I am trying to implement a
>> collection on it. I am implementing it as m:n relationship with an
>> indirection table and using @ojb.collection foreignkey and
>> remote-foreignkey xdoclet tags.
>>
>> Anyone have a clue what my problem is? I'm lost...
>>
>> -Gus
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-user-help@db.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org