Expose XAConnectionFactory and ConnectionFactory via JNDI

[glassfishrobot]

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.

[glassfishrobot]

Reported by blabno

[glassfishrobot]

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]

blabno said:
Arjan, could you elaborate more on xa/non-xa? This is what I'm actually focusing on.

[glassfishrobot]

arjan_t said:

could you elaborate more on xa/non-xa?

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]

This issue was imported from java.net JIRA JAVAEE_SPEC-32