[ https://issues.jboss.org/browse/AS7-3143?page=com.atlassian.jira.plugin.s... ] Markus Doering updated AS7-3143: -------------------------------- Attachment: TestEAR.ear.zip The EAR to reproduce the issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3143?page=com.atlassian.jira.plugin.s... ] Stephen Coy commented on AS7-3143: ---------------------------------- The parameters to javax.jms.Connection#createSession(...) are supposed to be ignored in an EJB container (§13.3.5 of the EJB 3.1 spec). The fact that Markus has experienced different behaviour with this would also be a bug I expect. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3143?page=com.atlassian.jira.plugin.s... ] Vlastimil Eliáš updated AS7-3143: --------------------------------- Reporter: Markus Döring (was: Markus Doering) Forum Reference: http://community.jboss.org/thread/176509 (was: http://community.jboss.org/thread/176509) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3143?page=com.atlassian.jira.plugin.s... ] Carlo de Wolf commented on AS7-3143: ------------------------------------ I see both messages being processed correctly. {noformat} 13:47:26,335 INFO [de.tccproducts.test.JMSTest1] (http-localhost-127.0.0.1-8080-2) beforeSend 13:47:26,531 INFO [de.tccproducts.test.TestServiceBean] (http-localhost-127.0.0.1-8080-2) Nontransactional message send... 13:47:31,531 INFO [de.tccproducts.test.TestServiceBean] (http-localhost-127.0.0.1-8080-2) Nontransactional message commit... 13:47:31,537 INFO [de.tccproducts.test.JMSTest1] (http-localhost-127.0.0.1-8080-2) afterSend 13:47:31,541 INFO [de.tccproducts.test.TestMDB] (Thread-1 (group:HornetQ-client-global-threads-1183997638)) Processing message: HornetQMessage[ID:16f0a30a-3609-11e1-87a7-0024d7e46570]:PERSISTENT 13:48:05,115 INFO [de.tccproducts.test.JMSTest2] (http-localhost-127.0.0.1-8080-2) beforeSend 13:48:05,115 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (http-localhost-127.0.0.1-8080-2) IJ000612: Destroying connection that could not be successfully matched: org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@24acafd0[state=NORMAL managed connection=org.hornetq.ra.HornetQRAManagedConnection@51229f49 connection handles=0 lastUse=1325594851537 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@38079b3c pool internal context=org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool@2ff25b81 xaResource=XAResourceWrapperImpl@60357793[xaResource=org.hornetq.ra.HornetQRAXAResource(a)7b609ce0 pad=false overrideRmValue=false productName=HornetQ productVersion=2.0 jndiName=java:/JmsXA] txSync=null] 13:48:05,123 INFO [de.tccproducts.test.TestServiceBean] (http-localhost-127.0.0.1-8080-2) Transactional message send... 13:48:10,123 INFO [de.tccproducts.test.TestServiceBean] (http-localhost-127.0.0.1-8080-2) Transactional message commit... 13:48:10,126 INFO [de.tccproducts.test.JMSTest2] (http-localhost-127.0.0.1-8080-2) afterSend 13:48:10,127 INFO [de.tccproducts.test.TestMDB] (Thread-0 (group:HornetQ-client-global-threads-1183997638)) Processing message: HornetQMessage[ID:2df17620-3609-11e1-87a7-0024d7e46570]:PERSISTENT {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3143?page=com.atlassian.jira.plugin.s... ] Markus Döring commented on AS7-3143: ------------------------------------ Sorry, I changed the ConnectionFactory from java:/ConnectionFactory to java:/JmsXA for testing and did not change it back for the new build with sources. As statet above, java:/JmsXA does work correctly. Will upload a new build in a few minutes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3143?page=com.atlassian.jira.plugin.s... ] Carlo de Wolf commented on AS7-3143: ------------------------------------ Using ConnectionFactory entails DIY transactional behaviour. So when using a transacted session it must be manually committed: {code} LOG.info("Transactional message commit..."); + session.commit(); {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3143?page=com.atlassian.jira.plugin.s... ] Carlo de Wolf commented on AS7-3143: ------------------------------------ The behaviour changed with HORNETQ-515. Previously you would silently get a XA capable connection factory. Now it must be explicitly configured. To differentiate properly with UserTransaction: this is not about a container managed transaction or user managed transaction, this is a JMS local transaction as specified in JMS 1.1 FR 4.4.7. Although it is not pretty to allow JMS local transaction in the mix (java:/ConnectionFactory) there is no rule that prohibits such usage (AFAIK). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3143?page=com.atlassian.jira.plugin.s... ] Carlo de Wolf resolved AS7-3143. -------------------------------- Fix Version/s: 7.1.0.Final Resolution: Rejected -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3143?page=com.atlassian.jira.plugin.s... ] Carlo de Wolf commented on AS7-3143: ------------------------------------ The Transaction Manager does not play a role in a JMS local transaction. That part is managed by the JMS provider. Any transactional resources used outside of JMS will be enlisted on the TM transaction. So you'll not see the TM reporting a warning. It really is *not pretty*. ;-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/AS7-3143?page=com.atlassian.jira.plugin.s... ] Andrig Miller commented on AS7-3143: ------------------------------------ With persistent messages, and HornetQ as the only messaging provider in AS 7.x, don't we always have to use java:/JmsXa? With the old JBoss Messaging, if you placed the schema in the same database with your application schema, you would always have a 1 phase commit for persistent messages. Since HornetQ uses a journal, there is no way to optimize for a one phase commit, as you, by definition, always have to resource managers, no? I think this is a migration issue that needs to be documented, and perhaps even changed in the configuration from a default perspective. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira