[
https://issues.apache.org/jira/browse/OPENJPA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517395
]
Craig Russell commented on OPENJPA-295:
---------------------------------------
> My patch doesn't use a different TSR per thread, it just put a different
> instance of the javax.transaction.Transaction into the ThreadLocal, so that a
> different Transaction is used per thread (as per the JTA spec).
Well, we are only using the Transaction interface to do a small number of
things, and while it may seem attractive to use a ThreadLocal for this, it's a
bit bizarre because the same ThreadLocal is permanently assigned to the thread
so the Transaction never changes. This is not per the JTA spec ;-)
> That being said, there are plenty of other solutions to this problem. The
> advantage I see to my solution is that it doesn't introduce additional
> unnecessary synchronizatin into the findTransactionalBroker() method.
> However, even if a different solution is desired, my patch should probably be
> applied anyway, since having the same Transaction instance being used from
> multiple threads might break other assumptions elsewhere.
I think in the case of TSR, there is a much more elegant solution to
findTransactionalBroker, by using the getResource and setResource methods.
These methods should be much more efficient than our own synchronized
_transactional.get(key). Then the only use for _transactional is to make sure
that there are no outstanding transactions in progress when we try to close the
EntityManagerFactory.
So I'd like to extend ManagedRuntime with a findTransactionalBroker method that
would allow the RegistryManagedRuntime to be more efficient, and put the
current AbstractBrokerFactory's implementation into AbstractManagedRuntime.
> 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, 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.
