openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig Russell (JIRA)" <>
Subject [jira] Updated: (OPENJPA-295) ArrayIndexOutofBoundsException when under load and within a managed Transaction
Date Fri, 03 Aug 2007 02:16:52 GMT


Craig Russell updated OPENJPA-295:

    Attachment: openjpa-295.patch

Michael said:
>That being said I think there are cases where we will need to return a separate TransactionFacade
instance if the transaction key is different. 

TSR was designed so this is not needed. Getting the transaction key is supposed to be a trivial
operation so there's no need to remember (cache) it.

>If the container has suspended that current transaction and started a new one (a bean
method with TX_REQUIRES_NEW calls another bean method with TX_REQUIRES_NEW) we'll need a separate
key to the _transactions collection. If they used the same key then we'd run into problems
the first time an AfterCompletion event is fired. 

As long as we never cache the transaction key, but look it up each time we need it, we're
good. That is, any time you need to do anything with the transaction key, get it from the
ManagedRuntime. It's guaranteed to give you the *current* transaction key. 

The usage of the cached key in RemoveTransactionSync is ok because it's called after the transaction
which was registered has completed. And the broker you want to remove from _transactional
has that key.

I've attached a new patch that makes the internally cached transaction key an Object instead
of a Transaction.

> ArrayIndexOutofBoundsException when under load and within a managed Transaction
> -------------------------------------------------------------------------------
>                 Key: OPENJPA-295
>                 URL:
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jpa
>    Affects Versions: 1.0.0
>         Environment: openjpa running under WebSphere development builds, as well as Geronimo
development builds
>            Reporter: Rob Wisniewski
>            Priority: Blocker
>         Attachments: OPENJPA-295.diff.txt, openjpa-295.patch, openjpa-295.patch, OPENJPA295.patch
> Recent development builds of our WAS products as well as the Geronimo project are seeing
exceptions when running under load.  An example of the exception is below:
> Caused by: 
> java.lang.ArrayIndexOutOfBoundsException
> 	at java.util.ArrayList.add(
> 	at org.apache.openjpa.kernel.AbstractBrokerFactory.syncWithManagedTransaction(
> 	... 39 more
> This is the deepest trace I can get with the actual exception, but the wrappering exception
shows this stack trace for geronimo:
> <1.0.0-SNAPSHOT-SNAPSHOT nonfatal general error> org.apache.openjpa.persistence.PersistenceException:
> 	at org.apache.openjpa.kernel.AbstractBrokerFactory.syncWithManagedTransaction(
> 	at org.apache.openjpa.kernel.BrokerImpl.initialize(
> 	at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(
> 	at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(
> 	at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(
> 	at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(
> 	at org.apache.geronimo.persistence.CMPEntityManagerTxScoped.createEntityManager(
> 	at org.apache.geronimo.persistence.CMPEntityManagerTxScoped.getEntityManager(
> 	at org.apache.geronimo.persistence.CMPEntityManagerTxScoped.createNamedQuery(
> 	at org.apache.geronimo.samples.daytrader.ejb3.TradeSLSBBean.getClosedOrders(
> This is happening in two separate products with two different JTA implementations, and
also both of these products were working at one point.
> Any ideas?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message