-
15. Re: ARJUNA016051: thread is already associated with a transaction!
xiumeteo Apr 15, 2013 10:46 AM (in response to surajyonzon)Hi, i have a very similar issue with ARJUNA but im using arquillian-persistence-extension i trying to perform a persist operation in a test after seed the database with my custom dataset, but during the execution of the test, the test fail because ARJUNA016051: thread is already associated with a transaction!
There is the code that i'm using
@ApplyScriptBefore( "prueba1.sql" )
@ApplyScriptAfter( "prueba1_unload.sql" )
@Test(expected = RollbackException.class)
public void testpersistWithaApplyScriptBefore() throws Exception {
manager.clear();
App app = new App();
app.setAppName("prueba");
app.setDescription("prueba");
app.setCreatedAt(new Date());
app.setModifiedAt(new Date());
transaction.begin();
manager.persist(app);
transaction.commit();
// manager.clear();
}
And yes, i tried without the transaction and of course, the test fails because the exception is never launched. Thanks in advance.
UPDATE---
I'm working on PostgresSQL and Jboss remote 7.1.1
-
16. Re: ARJUNA016051: thread is already associated with a transaction!
smarlow Apr 15, 2013 11:22 AM (in response to xiumeteo)Same answer as before, enable TRACE logging for org.jboss.as.jpa + arjuna (https://docs.jboss.org/author/display/AS72/JPA+Reference+Guide#JPAReferenceGuide-Troubleshooting). For the tranaction that is unexpectedly associated with the thread, look up the first reference to that transaction in the server.log. That gives you the origin of the unexpected transaction. Then figure out why its still associated with the thread.
-
17. Re: ARJUNA016051: thread is already associated with a transaction!
xiumeteo Apr 16, 2013 10:32 AM (in response to smarlow)Thanks!
i am looking in the log right now and this is what i found, but i'm very newbie, so if you can give me some orientation here would be great!
09:13:38,826 TRACE [com.arjuna.ats.arjuna] (pool-16-thread-3) ReaperElement::ReaperElement ( BasicAction: 0:ffffac10441a:-1008d529:516d52df:93 status: ActionStatus.RUNNING, 300 )
09:13:38,826 TRACE [com.arjuna.ats.arjuna] (Transaction Reaper) ReaperThread.run ()
09:13:38,826 TRACE [com.arjuna.ats.arjuna] (Transaction Reaper) TransactionReaper::check ()
09:13:38,826 TRACE [com.arjuna.ats.arjuna] (Transaction Reaper) TransactionReaper::check - comparing 1366121918826
09:13:38,826 TRACE [com.arjuna.ats.arjuna] (Transaction Reaper) Thread Thread[Transaction Reaper,5,main] sleeping for 300000
09:13:38,842 TRACE [org.jboss.as.jpa] (pool-16-thread-3) pu search for name '' inside of test.war
09:13:38,842 TRACE [org.jboss.as.jpa] (pool-16-thread-3) findWithinDeployment check '' against pu 'amModel'
09:13:38,842 TRACE [org.jboss.as.jpa] (pool-16-thread-3) findWithinDeployment matched '' against pu 'amModel'
09:13:38,842 TRACE [org.jboss.as.jpa] (pool-16-thread-3) pu search found test.war#amModel
09:13:38,842 TRACE [com.arjuna.ats.jta] (pool-16-thread-3) BaseTransaction.begin
09:13:38,842 TRACE [com.arjuna.ats.jta] (pool-16-thread-3) TransactionImple.getStatus
09:13:38,858 TRACE [com.arjuna.ats.jta] (pool-16-thread-3) BaseTransaction.getStatus
09:13:38,858 TRACE [com.arjuna.ats.jta] (pool-16-thread-3) TransactionImple.getStatus
09:13:38,858 TRACE [com.arjuna.ats.jta] (pool-16-thread-3) BaseTransaction.commit
09:13:38,858 TRACE [com.arjuna.ats.jta] (pool-16-thread-3) TransactionImple.commitAndDisassociate
09:13:38,858 TRACE [com.arjuna.ats.arjuna] (pool-16-thread-3) BasicAction::End() for action-id 0:ffffac10441a:-1008d529:516d52df:93
09:13:38,858 TRACE [com.arjuna.ats.arjuna] (pool-16-thread-3) BasicAction::removeChildThread () action 0:ffffac10441a:-1008d529:516d52df:93 removing TSThread:3
09:13:38,858 TRACE [com.arjuna.ats.arjuna] (pool-16-thread-3) BasicAction::removeChildThread () action 0:ffffac10441a:-1008d529:516d52df:93 removing TSThread:3 result = true
09:13:38,858 TRACE [com.arjuna.ats.arjuna] (pool-16-thread-3) TransactionReaper::remove ( BasicAction: 0:ffffac10441a:-1008d529:516d52df:93 status: ActionStatus.COMMITTED )
09:13:38,858 ERROR [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-16-thread-3) Failed: com.donde.am.entities.AppTestIssue6.testpersistWithaApplyScriptBefore: javax.transaction.NotSupportedException: BaseTransaction.checkTransactionState - ARJUNA016051: thread is already associated with a transaction!
-
18. Re: ARJUNA016051: thread is already associated with a transaction!
smarlow Apr 16, 2013 10:19 PM (in response to xiumeteo)I don't see enough of your server.log above. I expect to see either "created new TransactionScopedEntityManager" or maybe "[transaction scoped EntityManager]: reuse entity manager session already in tx TransactionImple" trace messages (showing how the entity manager was obtained).
Also, it looks a little odd (not sure how JBoss AS is used in your test) how we go from:
09:13:38,842 TRACE [org.jboss.as.jpa] (pool-16-thread-3) pu search found test.war#amModel
And the next line is:
09:13:38,842 TRACE [com.arjuna.ats.jta] (pool-16-thread-3) BaseTransaction.begin
-
19. Re: ARJUNA016051: thread is already associated with a transaction!
xiumeteo Apr 17, 2013 9:42 AM (in response to smarlow)Hi, well i search over and over around this section of the server.logger and never see something like you describe...this is the full trace
Also, i tried comitting the transaction and open another, but it works in the way that i can create another transaction but when i tried to commit the new open transaction i received the" No transaction!" error
-
20. Re: ARJUNA016051: thread is already associated with a transaction!
smarlow Apr 18, 2013 8:33 AM (in response to xiumeteo)Cesar,
Could you try again with the EAP alpha built from AS7 which has release date of 2013-03-07. If something newer shows up on that page, use that instead.
http://www.jboss.org/jbossas/downloads.html
If that doesn't help you could pastebin your Arquillian test source and someone might see a problem with it.
Scott
-
22. Re: ARJUNA016051: thread is already associated with a transaction!
surajyonzon Jul 5, 2013 4:22 AM (in response to blabno)Hi Bernard,
Its a very nice Post. The above post seems to be quite true about the given seam transaction's situations. But what about automatic transaction management performing by container itself? I have been using CMT Transaction, which is basically managed by EJB container automatically, in that case how can we solve the problem? I am still facing the same kind of problem. I am using EJB 3.1, JPA with Hibernate and Prime Faces 3.3.1. Can you please give us some ideas on this matter?