[ http://jira.jboss.com/jira/browse/JBAS-4481?page=all ] Dimitris Andreadis updated JBAS-4481: ------------------------------------- Fix Version/s: JBossAS-4.2.1.CR1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365088 ] Gavin King commented on JBAS-4481: ---------------------------------- No, all I needed to do was stick a breakpoint somewhere in my app, and wait til I saw this message: 17:59:45,240 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_58] - Abort of action id -3f57fe9c:c5a3:466f14e4:4e invoked while multiple threads active within it. 17:59:45,241 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.CheckedAction_2] - CheckedAction::check - atomic action -3f57fe9c:c5a3:466f14e4:4e aborting with 1 threads active! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365139 ] Mark Little commented on JBAS-4481: ----------------------------------- If a timeout goes off, the transaction will be rolled back by a separate thread but it cannot (not required to by the standards) do thread-to-transaction disassociation. What the original creating thread should do is find out the transaction has rolled back (e.g., when it tries to do some other work within the transaction it'll get an exception), and do a rollback anyway. That is the only way you can guarantee to get the thread-to-transaction association changed. When you say that the request ends and the thread returns to the pool, does that thread terminates the transaction via UT? It would help to see the code fragment that's responsible for this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365144 ] Gavin King commented on JBAS-4481: ---------------------------------- "If a timeout goes off, the transaction will be rolled back by a separate thread but it cannot (not required to by the standards) do thread-to-transaction disassociation. What the original creating thread should do is find out the transaction has rolled back (e.g., when it tries to do some other work within the transaction it'll get an exception), and do a rollback anyway. That is the only way you can guarantee to get the thread-to-transaction association changed." This is totally absurd. Are you serious? The transaction is Status.ROLLEDBACK, and the application should call rollback() on it? What a ridiculous assertion. Besides, UNDER NO CIRCUMSTANCES should ANY request to the application server POSSIBLY create a circumstance where the application server must be restarted before it can serve other requests. Stop making excuses and fix this clearly broken behavior. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365167 ] Mark Little commented on JBAS-4481: ----------------------------------- "FYI, there may be an issue" There is an issue in this situation if your application thread was calling rollback on the timed-out transaction during cleanup. commit should have been fine, i.e., the application thread would have been disassociated from the transaction correctly if commit was called, but not rollback. Jonathan is working on producing a new version now. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365218 ] Gavin King commented on JBAS-4481: ---------------------------------- "In a multi-threaded environment where multiple threads may be running in the scope of the same transaction " In a Java EE environment, "multiple threads ... running in the scope of the same transaction" is a vanishingly rare case and one that I'm not even convinced is actually supported (there does not seem to be any standard way to pass a txn context between container threads, and you're not supposed to start your own threads). Perhaps I'm wrong on this, but that's what I've always understood. Regardless, it is clear that the association should be cleaned up before the thread is returned to the thread pool, . "What JBossTS does (and has always done) is roll back the transaction that has timed out and leave it associated with the various threads." Those threads are in a THREAD POOL, and are going to be re-used in future requests that have nothing to do with the original transaction. That is why the Java EE spec (read it) *requires* that you clean up any open transaction at the end of every request. The Java EE spec is smart enough to know that an application server can't assume that applications are "well-behaved", as defined by Mark Little this month (where the definition of "well-behaved" changes arbitrarily between minor releases of the application server in question). Application servers aren't supposed to fall over in a heap just because an application fails to clean up in an exceptional case in one thread. That's the whole point. Besides which, this is a strange definition of "well-behaved". How can it possibly make sense to require a call to rollback() or commit() on a transaction with the status ROLLEDBACK? The transaction is rolled back. Why should I need to roll it back *again*? Now, if it was ROLLBACK_ONLY, that's a different case, a well-behaved application should to something to it, but even in this case the Java EE spec requires that the association to the current (pooled) thread is destroyed before returning the thread to the pool. Actually I'm kinda confused how we even got to this status in the first place, the definition of Status.ROLLEDBACK states: "A transaction is associated with the target object and the outcome has been determined as rollback. It is likely that heuristics exist, otherwise the transaction would have been destroyed and NoTransaction returned." I don't see why there are heuristics in the case of a simple transaction timeout against a single resource? Is that normal? Why didn't we just go straight to NO_TRANSACTION? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365222 ] Gavin King commented on JBAS-4481: ---------------------------------- Excuse me, what the spec actually says is: * JTA transactions should be started and completed in the thread in which the service method is called. Additional threads that are created for any purpose should not attempt to start JTA transactions. * If a web component creates a thread, the J2EE platform must ensure that the newly created thread is not associated with any JTA transaction. * Transactions may not span web requests from a client. A web component starts a transaction in the service method of a servlet (or, for a JSP page, the service method of the equivalent JSP page Implementation Class) and it must be completed before the service method returns. Returning from the service method with an active transaction context is an error. _The_web_container_is_required_ to detect this error and abort the transaction. Furthermore, neither Transaction nor UserTransaction provide any kind of join() method, and suspend()/resume() on TransactionManager explicitly outlaws resuming a tx that is already associated with another thread. So I'm totally confused about how, according to spec, an application could possibly have a single tx associated with >1 thread. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365227 ] Gavin King commented on JBAS-4481: ---------------------------------- "You're allowed to pass Transaction via suspend and resume in JTA." AFAICT, this is not true. resume() does not support resuming by multiple threads. Regardless, the app is not allowed to call TransactionManager anyway. The only thing its got is UserTransaction. "A thread can't just start a transaction and ignore it." Correct, it is an error to do that, and the spec says (for good reason): "Returning from the service method with an active transaction context is an error. _The_web_container_is_required_ to detect this error and abort the transaction." "Is this thread created by Seam, Hibernate or the application server." This thread is in Tomcat's thread pool, of course. "I already told you why we can't break the thread-to-transaction association in the case of timeout." Whynot? What spec says that? And yes, you can, and you must. Otherwise thread goes back in Tomcat's pool with a garbage transaction object associated with it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365234 ] Gavin King commented on JBAS-4481: ---------------------------------- "what JTA allows and what JEE allows are sometimes different" Which is why I filed this bug against JBoss AS, not against the TM. "I've been telling you what we do and why we do it in general terms. You're obviously not interested in that, so I'll stop. " I'm definitely not interested in that. I'm interested in fixing the bug in JBoss 4.2 "Well you're wrong. You can't resume if there's already a transaction active on the thread, but you can resume the same transaction into multiple threads. " Ooops, you're right, and this is an optional feature supported but not required by JTA. My bad. Nevertheless, its entirely academic, since the app is not allowed to get a TM in the first case. "Not the timeout thread. But *something* obviously needs to." Right, so can we quit the discussion and just fix the bug now? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=all ] Jonathan Halliday reassigned JBAS-4481: --------------------------------------- Assignee: Gavin King (was: Jonathan Halliday) In the absence of a suppiled test case, please grab the jbossjta.jar from http://repository.jboss.com/jboss/jbossts14/snapshot/lib/ , install it over the current one in your AS 4.2 server/lib and let me know if it fixes the issue. thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365466 ] Michael JOnes commented on JBAS-4481: ------------------------------------- BTW. About 5 minutes ago. I got this exception and a hanging JBoss on a production site. Here is the last entries in the log: - 12:03:03,012 WARN [ValidatorResources] Form 'ProductForm' not found for locale 'en_NZ' 12:07:41,977 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.BasicAction_58] - Abort of action id -3f57fdff:12dd:466f4b3f:94029 invoked while multiple threads active within it. 12:07:41,977 WARN [arjLoggerI18N] [com.arjuna.ats.arjuna.coordinator.CheckedAction_2] - CheckedAction::check - atomic action -3f57fdff:12dd:466f4b3f:94029 aborting with 1 threads active! It did not work until I restarted it. I don't know how to replicate it as it is the first time I have seen it. It may have occured at the same time as a user triggered a call to the loadCache() method of this EJB: - @Stateless @TransactionManagement (TransactionManagementType.CONTAINER) public class EStoreServerCacheManagerBean implements EStoreServerCacheManager, EStoreServerCacheManagerLocal { /** * Called when the cache needs to be refreshed from the database */ @TransactionTimeout(value=600) //10 Minutes to load all the summaries public void loadCache() { logger.debug("loadCache called"); Store[] stores = storeManager.getStores(); for(Store store : stores) { EStoreObjectSpace.loadCache(store); } } } EStoreObjectSpace.loadCache() is defined as: - public static synchronized EStoreCache loadCache(Store store) { } Could it be that this method is synchronized ? Does any one have any recommendations for debugging this? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365488 ] Mark Little commented on JBAS-4481: ----------------------------------- Jonathan's going back over his test. Michael, although your issue may be related that's not necessarily the case. Could you create another JIRA so we can track it and manage it separately for now? Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365494 ] Jonathan Halliday commented on JBAS-4481: ----------------------------------------- I've attached a simple webapp I've been using to look at this issue. It recreate the problem Gavin sees when running the TS 4.2.3.SP4. It also appears to show the problem is resolved when running the TS snapshot. If you disagree with this assesment, please provide an alternative test case. unpack the exploded .war into server/default/deploy and invoke http://localhost:8080/test4481/test output with JBossTS 4.2.3.SP4: remember this Thread id, we want see the next call is on the same Thread to show it's reusable Thread=Thread[http-127.0.0.1-8080-1,5,jboss] our Thread should be fresh from the pool, with no transaction associated: app server transaction status (hopefully 6 STATUS_NO_TRANSACTION): 6 transaction manager transaction status (hopefully null): null setting 2 second tx timeout... starting a transaction... app server transaction status (hopefully 0 STATUS_ACTIVE): 0 transaction manager transaction status (hopefully ActionStatus.RUNNING): TransactionImple < ac, BasicAction: -3f57fffe:898a:46725aaf:3e status: ActionStatus.RUNNING > sleeping 5 seconds, i.e. long enough for the tx to timeout app server transaction status (hopefully 4, STATUS_ROLLEDBACK, becuse the timeout has triggered already) : 4 transaction manager transaction status (hopefully ActionStatus.ABORTED: TransactionImple < ac, BasicAction: -3f57fffe:898a:46725aaf:3e status: ActionStatus.ABORTED > trying to resolve the transaction, which we must do because we are the owning thread... caught an expected exception, since the tx is already resolved (hopefully java.lang.IllegalStateException)... java.lang.IllegalStateException: [com.arjuna.ats.internal.jta.transaction.arjunacore.inactive] [com.arjuna.ats.internal.jta.transaction.arjunacore.inactive] The transaction is not active! at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1323) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:163) at MyServlet.doGet(MyServlet.java:61) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) app server transaction status (hopefully 6 STATUS_NO_TRANSACTION becuse the tx is now cleaned up): 4 transaction manager transaction status (hopefully null): TransactionImple < ac, BasicAction: -3f57fffe:898a:46725aaf:3e status: ActionStatus.ABORTED > finished. (invoke it again)... remember this Thread id, we want see the next call is on the same Thread to show it's reusable Thread=Thread[http-127.0.0.1-8080-1,5,jboss] our Thread should be fresh from the pool, with no transaction associated: app server transaction status (hopefully 6 STATUS_NO_TRANSACTION): 4 transaction manager transaction status (hopefully null): TransactionImple < ac, BasicAction: -3f57fffe:898a:46725aaf:3e status: ActionStatus.ABORTED > setting 2 second tx timeout... starting a transaction... 10:25:19,477 INFO [STDOUT] v: 4 10:25:19,478 INFO [STDOUT] v: TransactionImple < ac, BasicAction: -3f57fffe:898a:46725aaf:3e status: ActionStatus.ABORTED > 10:25:38,814 ERROR [STDERR] javax.transaction.NotSupportedException 10:25:38,815 ERROR [STDERR] at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.begin(BaseTransaction.java:79) 10:25:38,815 ERROR [STDERR] at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.begin(BaseTransactionManagerDelegate.java:77) 10:25:38,816 ERROR [STDERR] at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.begin(ServerVMClientUserTransaction.java:124) output with JBossTS snapshot: remember this Thread id, we want see the next call is on the same Thread to show it's reusable Thread=Thread[http-127.0.0.1-8080-1,5,jboss] our Thread should be fresh from the pool, with no transaction associated: app server transaction status (hopefully 6 STATUS_NO_TRANSACTION): 6 transaction manager transaction status (hopefully null): null setting 2 second tx timeout... starting a transaction... app server transaction status (hopefully 0 STATUS_ACTIVE): 0 transaction manager transaction status (hopefully ActionStatus.RUNNING): TransactionImple < ac, BasicAction: -3f57fffe:b13f:467251ee:7f status: ActionStatus.RUNNING > sleeping 5 seconds, i.e. long enough for the tx to timeout app server transaction status (hopefully 4, STATUS_ROLLEDBACK, becuse the timeout has triggered already) : 4 transaction manager transaction status (hopefully ActionStatus.ABORTED: TransactionImple < ac, BasicAction: -3f57fffe:b13f:467251ee:7f status: ActionStatus.ABORTED > trying to resolve the transaction, which we must do because we are the owning thread... caught an expected exception, since the tx is already resolved (hopefully java.lang.IllegalStateException)... java.lang.IllegalStateException: [com.arjuna.ats.internal.jta.transaction.arjunacore.inactive] [com.arjuna.ats.internal.jta.transaction.arjunacore.inactive] The transaction is not active! at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1360) at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:163) at MyServlet.doGet(MyServlet.java:61) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:580) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:595) app server transaction status (hopefully 6 STATUS_NO_TRANSACTION becuse the tx is now cleaned up): 6 transaction manager transaction status (hopefully null): null finished. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365534 ] Adrian Brock commented on JBAS-4481: ------------------------------------ Jonathon I just raised a subtask for the CachedConnectionValve and ejb BMT interceptor. This is the real issue. It is still really an application error to not invoke ut.rollback() or ut.commit() after a ut.begin() the purpose of those two interceptors is to trap when the application fails. http://wiki.jboss.org/wiki/Wiki.jsp?page=WhatIsTheCorrectPatternForUserTr... P.S. Why are we using JIRA as a forum? It's just noise and "garbage" itself. This whole bout of speculation should really have done in the forums and then the subtask (not this task) raised to fix the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365541 ] Gavin King commented on JBAS-4481: ---------------------------------- I should have added: (5) Nobody ever tests what happens to their application when a deadlock or other transaction timeout occurs. They find out when their system is under heavy production load. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365749 ] Adrian Brock commented on JBAS-4481: ------------------------------------ The EJB tests are done and tested on JBAS-4487. There is still an outstanding issue of having the same tests for web-apps. I've created a seperate sub-task fo that JBAS-4488. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=comments#action_12365994 ] Dimitris Andreadis commented on JBAS-4481: ------------------------------------------ Gavin, is it possible to check again using the latest build from Branch_4_2? Should be fixed now. https://svn.jboss.org/repos/jbossas/branches/Branch_4_2/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBAS-4481?page=all ] Gavin King reassigned JBAS-4481: -------------------------------- Assignee: Adrian Brock (was: Gavin King) Adrian, can you check an additional case. Our blog site when down today because of the following case: A transaction failed while accessing the database: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'STRING_VALUE' at row 1 at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2939) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1623) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1715) at com.mysql.jdbc.Connection.execSQL(Connection.java:3249) at com.mysql.jdbc.PreparedStatement.executeInternal(Prepared And (I believe) the tx was marked ROLLEDBACK. Subsequent attempts to begin() new transaction on the same thread failed. What should be the expected behavior of the appserver transaction in this case? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira