Hi Paul,
Nase, Paul R. wrote:
Jakob,
This issue is very difficult to reproduce (intermittent - probably related to multiple threads), so we cannot easily answer "what class is returned by collectionField.get(owner)".
It looks like your second code snippet is from OJB 1.0.1, I should reiterate that we are still on version RC6.
Plus we are wondering how thread safe this area of code is (in RC6)?
A PB instance itself is not threadsafe (intended behavior). Each thread have to use it's own PB instance or if you want to share a PB instance make sure that only one thread is active working on that instance.
regards, Armin
Thanks,
Paul
-----Original Message-----
From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Sunday, October 17, 2004 9:33 AM
To: OJB Users List
Subject: Re: ClassCastException in QueryReferenceBroker.
hi paul,
i think this problem should disappear when usinf proxy-prefetching-limit = 0. see QueryReferenceBroker#retrieveCollection
...
if (prefetchProxies && (m_retrievalTasks != null) && (cds.getProxyPrefetchingLimit() > 0) <<<<<< && (cds.getQueryCustomizer() == null) && (ProxyHelper.isCollectionProxy(value))) { if (addRetrievalTask(obj, cds)) { new PBCollectionProxyListener(obj, m_retrievalTasks, cds, cds.getProxyPrefetchingLimit()); } } ...
but imo this is not the way to do it. i assume that that class-cast-exception occurs when casing to CollectionProxyDefaultImpl:
protected void addThisListenerTo(Object owner) { PersistentField collectionField = ((CollectionDescriptor) _key).getPersistentField(); _listenedCollection = (CollectionProxyDefaultImpl) collectionField.get(owner); <<<<<<< _listenedCollection.addListener(this); }
can you confirm this ? what class is returned by collectionField.get(owner) ?
jakob
Nase, Paul R. schrieb:
We are currently on OJB RC6 and cannot move to OJB 1.0 at this time due to product release schedules. During multi-user/load testing, we occasionally see the following ClassCastException occurring:
Caused by: java.lang.ClassCastException
at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.addThisListenerTo(QueryReferenceBroker.java:835)
at org.apache.ojb.broker.core.QueryReferenceBroker$PBPrefetchingListener.<init>(QueryReferenceBroker.java:757)
at org.apache.ojb.broker.core.QueryReferenceBroker$PBCollectionProxyListener.<init>(QueryReferenceBroker.java:828)
at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollection(QueryReferenceBroker.java:510)
at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveCollections(QueryReferenceBroker.java:656)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.getDBObject(PersistenceBrokerImpl.java:1291)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.doGetObjectByIdentity(PersistenceBrokerImpl.java:1371)
at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveReference(QueryReferenceBroker.java:309)
at org.apache.ojb.broker.core.QueryReferenceBroker.retrieveReferences(QueryReferenceBroker.java:361)
at org.apache.ojb.broker.accesslayer.RsIterator.getObjectFromResultSet(Rs
Iterator.java:472)
From past postings, it appears that this could eliminated by setting proxy-prefetching-limit to 0. Could someone confirm if this is a correct resolution for these errors and also give me an idea of how this may impact our current performance?
Thanks in advance,
Paul
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
