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 Jay Sissom <js...@gmail.com> on 2006/06/22 01:19:42 UTC
ArrayIndexOutOfBoundsException
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:
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
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. 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
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: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: ArrayIndexOutOfBoundsException
Posted by Jay Sissom <js...@gmail.com>.
Thanks for your help. I'm glad this update will be in 1.0.5.
Jay
On 6/23/06, Armin Waibel <ar...@apache.org> wrote:
> Hi Eric,
>
> Westfall, Eric Curtis wrote:
> > Here is a JIRA issue which describes the problem and the fix along with
> > the fixed version of PersistenceBrokerAbstractImpl attached.
> >
> > http://issues.apache.org/jira/browse/OJB-114
> >
>
> Many thanks for the patch! I checked in the new version of
> PBAbstractImpl (in OJB_1_0_RELEASE branch) and close the issue in JIRA.
>
>
> > It seems like if there was a way to get rid of the use of the finalize()
> > method in this context that would be a superior long term solution.
>
> I think this isn't possible, because you can't decide whether or not a
> started Iterator (Iterator it = broker.getIteratorByQuery(q)) will be
> used later. Only if
> - the user does a complete loop
> - the PB was closed (all connection resources closed)
> - the Iterator instance itself was GC
> it's allowed to close the underlying DB resources.
>
> Nevertheless, I look forward to your suggestions ;-)
>
> regards,
> Armin
>
>
> > That way you wouldn't have to worry about the cost of both running the
> > finalize method and synchronizing access to the underlying collections.
> > However that may or may not be possible. I'm not really too familiar
> > with the codebase ;)
> >
> > Thanks,
> > Eric
> >
> >> -----Original Message-----
> >> From: Jay Sissom [mailto:jsissom@gmail.com]
> >> Sent: Thursday, June 22, 2006 11:38 AM
> >> To: OJB Users List
> >> Subject: Re: ArrayIndexOutOfBoundsException
> >>
> >> Unfortunately, I don't have a simple, repeatable test case right now.
> >> This happens on a long running process and is related to the GC.
> >>
> >> We took the code in CVS mentioned in your email and tried it, but it
> >> didn't solve the problem. We added some synchronizing to it and that
> >> did solve it.
> >>
> >> This problem might have started when we switched to JDK 1.5. It
> >> happens on a Mac and Linux so it isn't based on a specific
> >> implementation. I'm not sure about this, but it could be when this
> >> started.
> >>
> >> We'll send the patch we made to make the problem go away a little
> > later.
> >> Thanks
> >> Jay
> >>
> >>
> >> On 6/22/06, Armin Waibel <ar...@apache.org> wrote:
> >>> 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(
> > Un
> >> known
> >>> 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.notifiyStateLis
> > te
> >> ner(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/or
> > g/
> >> apache/ojb/broker/util/IdentityArrayList.java?view=log
> > http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/or
> > g/
> >> 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
> > (U
> >> nknown
> >>>> Source)
> >>>> at
> >>>>
> > org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unkno
> > wn
> >>>> Source)
> >>>> at
> >>>>
> > org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
> > (U
> >> nknown
> >>>> Source)
> >>>> at
> >>>>
> > org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
> > (U
> >> nknown
> >>>> Source)
> >>>> at
> >>>>
> > org.springframework.orm.ojb.PersistenceBrokerTransactionManager.doCommit
> > (P
> >> ersistenceBrokerTransactionManager.java:251)
> >>>> at
> >>>>
> > org.springframework.transaction.support.AbstractPlatformTransactionManag
> > er
> >> .processCommit(AbstractPlatformTransactionManager.java:500)
> >>>> at
> >>>>
> > org.springframework.transaction.support.AbstractPlatformTransactionManag
> > er
> >> .commit(AbstractPlatformTransactionManager.java:473)
> >>>> at
> >>>>
> > org.springframework.transaction.interceptor.TransactionAspectSupport.doC
> > om
> >> mitTransactionAfterReturning(TransactionAspectSupport.java:267)
> >>>> at
> >>>>
> > org.springframework.transaction.interceptor.TransactionInterceptor.invok
> > e(
> >> TransactionInterceptor.java:106)
> >>>> at
> >>>>
> > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Ref
> > le
> >> ctiveMethodInvocation.java:170)
> >>>> at
> >>>>
> > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAo
> > pP
> >> roxy.java:176)
> >>>> at $Proxy87.postMainEntries(Unknown Source)
> >>>> at
> >>>>
> > org.kuali.module.gl.batch.PosterEntriesStep.performStep(PosterEntriesSte
> > p.
> >> java:44)
> >>>> at
> >>>>
> > org.kuali.core.batch.CommandLineStepRunner.main(CommandLineStepRunner.ja
> > va
> >> :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: 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
> >
> >
>
> ---------------------------------------------------------------------
> 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: ArrayIndexOutOfBoundsException
Posted by Armin Waibel <ar...@apache.org>.
Hi Eric,
Westfall, Eric Curtis wrote:
> Here is a JIRA issue which describes the problem and the fix along with
> the fixed version of PersistenceBrokerAbstractImpl attached.
>
> http://issues.apache.org/jira/browse/OJB-114
>
Many thanks for the patch! I checked in the new version of
PBAbstractImpl (in OJB_1_0_RELEASE branch) and close the issue in JIRA.
> It seems like if there was a way to get rid of the use of the finalize()
> method in this context that would be a superior long term solution.
I think this isn't possible, because you can't decide whether or not a
started Iterator (Iterator it = broker.getIteratorByQuery(q)) will be
used later. Only if
- the user does a complete loop
- the PB was closed (all connection resources closed)
- the Iterator instance itself was GC
it's allowed to close the underlying DB resources.
Nevertheless, I look forward to your suggestions ;-)
regards,
Armin
> That way you wouldn't have to worry about the cost of both running the
> finalize method and synchronizing access to the underlying collections.
> However that may or may not be possible. I'm not really too familiar
> with the codebase ;)
>
> Thanks,
> Eric
>
>> -----Original Message-----
>> From: Jay Sissom [mailto:jsissom@gmail.com]
>> Sent: Thursday, June 22, 2006 11:38 AM
>> To: OJB Users List
>> Subject: Re: ArrayIndexOutOfBoundsException
>>
>> Unfortunately, I don't have a simple, repeatable test case right now.
>> This happens on a long running process and is related to the GC.
>>
>> We took the code in CVS mentioned in your email and tried it, but it
>> didn't solve the problem. We added some synchronizing to it and that
>> did solve it.
>>
>> This problem might have started when we switched to JDK 1.5. It
>> happens on a Mac and Linux so it isn't based on a specific
>> implementation. I'm not sure about this, but it could be when this
>> started.
>>
>> We'll send the patch we made to make the problem go away a little
> later.
>> Thanks
>> Jay
>>
>>
>> On 6/22/06, Armin Waibel <ar...@apache.org> wrote:
>>> 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(
> Un
>> known
>>> 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.notifiyStateLis
> te
>> ner(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/or
> g/
>> apache/ojb/broker/util/IdentityArrayList.java?view=log
> http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/or
> g/
>> 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
> (U
>> nknown
>>>> Source)
>>>> at
>>>>
> org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unkno
> wn
>>>> Source)
>>>> at
>>>>
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
> (U
>> nknown
>>>> Source)
>>>> at
>>>>
> org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
> (U
>> nknown
>>>> Source)
>>>> at
>>>>
> org.springframework.orm.ojb.PersistenceBrokerTransactionManager.doCommit
> (P
>> ersistenceBrokerTransactionManager.java:251)
>>>> at
>>>>
> org.springframework.transaction.support.AbstractPlatformTransactionManag
> er
>> .processCommit(AbstractPlatformTransactionManager.java:500)
>>>> at
>>>>
> org.springframework.transaction.support.AbstractPlatformTransactionManag
> er
>> .commit(AbstractPlatformTransactionManager.java:473)
>>>> at
>>>>
> org.springframework.transaction.interceptor.TransactionAspectSupport.doC
> om
>> mitTransactionAfterReturning(TransactionAspectSupport.java:267)
>>>> at
>>>>
> org.springframework.transaction.interceptor.TransactionInterceptor.invok
> e(
>> TransactionInterceptor.java:106)
>>>> at
>>>>
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Ref
> le
>> ctiveMethodInvocation.java:170)
>>>> at
>>>>
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAo
> pP
>> roxy.java:176)
>>>> at $Proxy87.postMainEntries(Unknown Source)
>>>> at
>>>>
> org.kuali.module.gl.batch.PosterEntriesStep.performStep(PosterEntriesSte
> p.
>> java:44)
>>>> at
>>>>
> org.kuali.core.batch.CommandLineStepRunner.main(CommandLineStepRunner.ja
> va
>> :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: 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
RE: ArrayIndexOutOfBoundsException
Posted by "Westfall, Eric Curtis" <ew...@indiana.edu>.
Here is a JIRA issue which describes the problem and the fix along with
the fixed version of PersistenceBrokerAbstractImpl attached.
http://issues.apache.org/jira/browse/OJB-114
It seems like if there was a way to get rid of the use of the finalize()
method in this context that would be a superior long term solution.
That way you wouldn't have to worry about the cost of both running the
finalize method and synchronizing access to the underlying collections.
However that may or may not be possible. I'm not really too familiar
with the codebase ;)
Thanks,
Eric
> -----Original Message-----
> From: Jay Sissom [mailto:jsissom@gmail.com]
> Sent: Thursday, June 22, 2006 11:38 AM
> To: OJB Users List
> Subject: Re: ArrayIndexOutOfBoundsException
>
> Unfortunately, I don't have a simple, repeatable test case right now.
> This happens on a long running process and is related to the GC.
>
> We took the code in CVS mentioned in your email and tried it, but it
> didn't solve the problem. We added some synchronizing to it and that
> did solve it.
>
> This problem might have started when we switched to JDK 1.5. It
> happens on a Mac and Linux so it isn't based on a specific
> implementation. I'm not sure about this, but it could be when this
> started.
>
> We'll send the patch we made to make the problem go away a little
later.
>
> Thanks
> Jay
>
>
> On 6/22/06, Armin Waibel <ar...@apache.org> wrote:
> > 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(
Un
> known
> > >
> >
> > 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.notifiyStateLis
te
> ner(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/or
g/
> apache/ojb/broker/util/IdentityArrayList.java?view=log
> >
>
http://svn.apache.org/viewvc/db/ojb/branches/OJB_1_0_RELEASE/src/java/or
g/
> 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
(U
> nknown
> > >
> > > Source)
> > > at
> > >
>
org.apache.ojb.broker.core.PersistenceBrokerImpl.commitTransaction(Unkno
wn
> > > Source)
> > > at
> > >
>
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
(U
> nknown
> > >
> > > Source)
> > > at
> > >
>
org.apache.ojb.broker.core.DelegatingPersistenceBroker.commitTransaction
(U
> nknown
> > >
> > > Source)
> > > at
> > >
>
org.springframework.orm.ojb.PersistenceBrokerTransactionManager.doCommit
(P
> ersistenceBrokerTransactionManager.java:251)
> > >
> > > at
> > >
>
org.springframework.transaction.support.AbstractPlatformTransactionManag
er
> .processCommit(AbstractPlatformTransactionManager.java:500)
> > >
> > > at
> > >
>
org.springframework.transaction.support.AbstractPlatformTransactionManag
er
> .commit(AbstractPlatformTransactionManager.java:473)
> > >
> > > at
> > >
>
org.springframework.transaction.interceptor.TransactionAspectSupport.doC
om
> mitTransactionAfterReturning(TransactionAspectSupport.java:267)
> > >
> > > at
> > >
>
org.springframework.transaction.interceptor.TransactionInterceptor.invok
e(
> TransactionInterceptor.java:106)
> > >
> > > at
> > >
>
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Ref
le
> ctiveMethodInvocation.java:170)
> > >
> > > at
> > >
>
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAo
pP
> roxy.java:176)
> > >
> > > at $Proxy87.postMainEntries(Unknown Source)
> > > at
> > >
>
org.kuali.module.gl.batch.PosterEntriesStep.performStep(PosterEntriesSte
p.
> java:44)
> > >
> > > at
> > >
>
org.kuali.core.batch.CommandLineStepRunner.main(CommandLineStepRunner.ja
va
> :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: 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: ArrayIndexOutOfBoundsException
Posted by Jay Sissom <js...@gmail.com>.
Unfortunately, I don't have a simple, repeatable test case right now.
This happens on a long running process and is related to the GC.
We took the code in CVS mentioned in your email and tried it, but it
didn't solve the problem. We added some synchronizing to it and that
did solve it.
This problem might have started when we switched to JDK 1.5. It
happens on a Mac and Linux so it isn't based on a specific
implementation. I'm not sure about this, but it could be when this
started.
We'll send the patch we made to make the problem go away a little later.
Thanks
Jay
On 6/22/06, Armin Waibel <ar...@apache.org> wrote:
> 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: 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: ArrayIndexOutOfBoundsException
Posted by Armin Waibel <ar...@apache.org>.
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: 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