This repository was archived by the owner on Jan 30, 2019. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 30, 2019. It is now read-only.
Expose XAConnectionFactory and ConnectionFactory via JNDI #32
Description
We're creating javaee7 sample to show JMS XA and non-XA connection factory implications (javaee-samples/javaee7-samples#139, javaee-samples/javaee7-samples#158 (comment))
It works great on wildfly as it exposes both XAConnectionFactory (java:/JmsXA) and non-XA ConnectionFactory (java:/ConnectionFactory).
We would need servers to expose both factories.
Activity
glassfishrobot commentedon Dec 9, 2013
Reported by blabno
glassfishrobot commentedon Dec 18, 2013
arjan_t said:
In Java EE 7 you can optionally create your own connection factories in a standardized way in addition to using the default connection factory or ones (pre)-configured via proprietary means.
See http://docs.oracle.com/javaee/7/api/javax/jms/JMSConnectionFactoryDefinition.html
You can set there whether a factory should be transactional or not. There is subtle difference with XA/non-XA, but in practice I guess what you need is transactional/non-transactional, where transactional always seems to be XA-transactional as opposed to resource-local-transactional.
There's some more information and a very basic example to be found here: http://docs.oracle.com/javaee/7/tutorial/doc/jms-concepts005.htm
glassfishrobot commentedon Dec 19, 2013
blabno said:
Arjan, could you elaborate more on xa/non-xa? This is what I'm actually focusing on.
glassfishrobot commentedon Jan 5, 2014
arjan_t said:
If I'm not mistaken, JBoss is one of the few parties that differentiates between them. XA is a specific protocol and API that uses 2 phases (2PC, see http://en.wikipedia.org/wiki/Two-phase_commit_protocol) and allows multiple transactional XA resources to be enlisted within a transaction. Normally if you choose "transactional" in most servers then this is what you get.
There is however also something called a resource local transaction. With this a resource specific API is used to control the transaction boundaries (e.g. JDBC's Connection. With a non-xa TX, only a single resource can participate in a transaction. This means multiple operations against this single resource all happen or none of them happen, but they all have to be against the same resource.
Finally, non-transactional means what its name implies; when multiple operations against it are executed, they can succeed partially. When using a non-transactional resource within a (JTA) transaction it's invisible to that transaction and doesn't react to the commit or rollback operations that are done for the enclosing transaction.
In my experience XA is something that previous generations of programmers were told to be afraid of, but IMHO this is no longer valid. I'm not an expert on this matter, but I belief most implementations now auto optimize for cases when there's only 1 transactional resource participating in a transaction and it's thus no longer something that you need to avoid.
glassfishrobot commentedon Apr 25, 2017
This issue was imported from java.net JIRA JAVAEE_SPEC-32