[
https://issues.apache.org/jira/browse/OPENJPA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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: https://issues.apache.org/jira/browse/OPENJPA-295
> 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(ArrayList.java:378)
> at
> org.apache.openjpa.kernel.AbstractBrokerFactory.syncWithManagedTransaction(AbstractBrokerFactory.java:684)
> ... 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: null
> at
> org.apache.openjpa.kernel.AbstractBrokerFactory.syncWithManagedTransaction(AbstractBrokerFactory.java:690)
> at org.apache.openjpa.kernel.BrokerImpl.initialize(BrokerImpl.java:304)
> at
> org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:182)
> at
> org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:142)
> at
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:190)
> at
> org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:55)
> at
> org.apache.geronimo.persistence.CMPEntityManagerTxScoped.createEntityManager(CMPEntityManagerTxScoped.java:74)
> at
> org.apache.geronimo.persistence.CMPEntityManagerTxScoped.getEntityManager(CMPEntityManagerTxScoped.java:55)
> at
> org.apache.geronimo.persistence.CMPEntityManagerTxScoped.createNamedQuery(CMPEntityManagerTxScoped.java:259)
> at
> org.apache.geronimo.samples.daytrader.ejb3.TradeSLSBBean.getClosedOrders(TradeSLSBBean.java:335)
> 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.
