Hi Jay,
Jay Sissom wrote:
Hello, I am using OJB 1.0.4 and Spring 1.2.8. A spring interceptor is
handling transactions for me. All my OJB code is written using the
Spring PersistenceBrokerDaoSupport class.
I have a long running process that does quite a bit of data
manipulation. It is a single threaded app that starts up Spring, does
it's work, then ends. It runs from the command line.
All the database work happens in a single Spring managed transaction
against a single Oracle database.
If this process runs for a while, I will receive an exception in the
log like this:
If it isn't a concurrency issue (and it seems not, because you said
it's a single threaded app) it seems to be a bug in OJB.
2006-06-21 18:59:27,619 [Finalizer] ERROR
org.apache.ojb.broker.accesslayer.ReportQueryRsIterator :: Error when
try to remove RsIterator resource listener
java.lang.ArrayIndexOutOfBoundsException: 107
at
org.apache.ojb.broker.core.PersistenceBrokerAbstractImpl.removeListener(Unknown
This seems to indicate a concurrency problem. The
ArrayIndexOutOfBoundsException could only happen when at the same time
different threads remove listener objects. I think it could be that the
FinalizerThread conflicts with the application thread, because modern
gc's do no longer stop all app threads before gc run.
Anyway I can't reproduce your problem on my system. I run a test case
(against hsql and maxDB) which does many PB.getIteratorByQuery(q) calls
without iteration of all objects. This will prevent OJB from cleanup
RsIterator resources (because the iterator still has next objects). I
can see many info-log statements when RsIterator was finalized, but I
never get your concurrency issue. The GC runs within the
PB.getIteratorByQuery(q) calls but I don't know if app thread was
stopped between the GC runs.
Source)
at org.apache.ojb.broker.accesslayer.RsIterator.release(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.RsIterator.releaseDbResources(Unknown
Source)
at org.apache.ojb.broker.accesslayer.RsIterator.finalize(Unknown
Source)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83)
at java.lang.ref.Finalizer.access$100(Finalizer.java:14)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160)
This might happen many times during the process. The process doesn't
stop running after one of these exceptions.
yep, these exceptions are caught (and logged) by class RsIterator,
because call RsIterator.releaseDbResources cause "only" a resource
cleanup issue.
At the end of the run,
when Spring should commit the transaction, it does a rollback with
this message:
2006-06-21 19:09:19,786 [main] ERROR
org.springframework.orm.ojb.PersistenceBrokerTransactionManager ::
Commit exception overridden by rollback exception
java.lang.NullPointerException
at
org.apache.ojb.broker.core.PersistenceBrokerAbstractImpl.notifiyStateListener(Unknown
This is strange. But maybe it's a subsequent error caused by the
concurrency issue above.
Currently we don't use synchronized methods in listener handling
(because these methods are very often called).
For OJB 1.0.5 I reworked this section some time ago (using
IdentityArrayList for listener instead of array). If you replace the
following sources in your 1.0.4 release source and recompile the OJB-jar
(call "ant jar" on command line in db-ojb directory) we can try to fix
this for the upcoming release.
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/util/IdentityArrayList.java?view=log
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/org/apache/ojb/broker/core/PersistenceBrokerAbstractImpl.java?view=log
Or if possible get latest OJB version from SVN OJB_1_0_RELEASE branch,
build OJB jar and run your test again.
> It looks like the garbage collector is trying to collect an object
> that is being used. Has anyone seen this before?
Think this is the first time.
> Any ideas how it
> can be fixed?
Maybe we have to synchronize some methods in
PersistenceBrokerAbstractImpl - e.g. #removeListener
regards,
Armin
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerAbstractImpl.fireBrokerEvent(Unknown
Source)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unknown
Source)
at
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction(Unknown
Source)
at
org.springframework.orm.ojb.PersistenceBrokerTransactionManager.doCommit(PersistenceBrokerTransactionManager.java:251)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:500)
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:473)
at
org.springframework.transaction.interceptor.TransactionAspectSupport.doCommitTransactionAfterReturning(TransactionAspectSupport.java:267)
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:170)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:176)
at $Proxy87.postMainEntries(Unknown Source)
at
org.kuali.module.gl.batch.PosterEntriesStep.performStep(PosterEntriesStep.java:44)
at
org.kuali.core.batch.CommandLineStepRunner.main(CommandLineStepRunner.java:63)
2006-06-21 19:09:19,787 [main] ERROR
org.apache.ojb.broker.core.PersistenceBrokerImpl :: Broker is still in
PB-transaction, do automatic abort before close!
It looks like the garbage collector is trying to collect an object
that is being used. Has anyone seen this before? Any ideas how it
can be fixed?
Thanks
Jay
---------------------------------------------------------------------
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]
