search

javaee / javaee-spec

Java EE Platform Specification
https://javaee.github.io/javaee-spec
Other
389 stars 69 forks source link

Portable JNDI name for platform transaction manager #8

Closed glassfishrobot closed 11 years ago

glassfishrobot commented 12 years ago

Java EE mandates a (JTA) transaction manager to be present. There is however no standardized portable JNDI defined for this. Currently a variety of Java EE AS implementations use different names, e.g.:

| JNDI name | AS | | java:jboss/TransactionManager | JBoss AS 7 | | java:/TransactionManager | JBoss AS 4 ~ 6, JRun4 | | java:comp/TransactionManager | Resin 3.x | | java:appserver/TransactionManager | Sun Glassfish | | java:pm/TransactionManager | Borland, Sun | | javax.transaction.TransactionManager | BEA WebLogic | | java:comp/UserTransaction | Resin, Orion, JOnAS (JOTM) |

(list taken from Infinispan's GenericTransactionManagerLookup)

Some implementations (e.g. WebSphere), don't seem to register a transaction manager in JNDI at all.

For an end user this is troublesome, since various transactional products (ORMs, Caching solutions) now need to bother the user with finding this information for the particular AS the user is deploying that product on. Generic solutions that scan well known locations may fail when the user upgrades the AS or moves to another AS.

To increase portability, I would like to request to introduce a portable name for the platform transaction manager and mandate that this will be available in all conforming implementations. E.g. java:/TransactionManager.

glassfishrobot commented 12 years ago

Reported by arjan_t

glassfishrobot commented 11 years ago

ldemichiel said: This issue was discussed in the expert group, and there were sufficient objections raised against it to not include it.

glassfishrobot commented 11 years ago

arjan_t said: Just wondering, what was the main objection? The fact that a transaction manager should not be accessible at all, or something else? Thanks!

glassfishrobot commented 11 years ago

ldemichiel said: IIRC, it was seen as compromising the container's ability to manage the transaction context.

glassfishrobot commented 11 years ago

arjan_t said: Okay, I see. Thanks for the quick answer.

It does beg the question though if there's anything we can do about the situation that an amount of (popular) software products use the transaction manager anyway, just in a non-portable way. Can their needs be satisfied in another way, without using this potentially harmful transaction manager?

Also, as can be seen in this issue's description, the majority of the application servers (including the reference implementation), make the transaction manager available anyway in JNDI. Is that in conflict with the idea that it compromises the container, or is user code simply not supposed to know about these JNDI entries (e.g. are they supposed to be for internal usage only?)

glassfishrobot commented 11 years ago

ldemichiel said: That one of the reasons that TransactionSynchronizationRegistry was introduced. Also, our design of the new transactional interceptors was designed to avoid the need to expose the TM in JNDI.

We could consider revisiting this issue in Java EE 8. If so, it would be helpful to know just what functionality users needed (and why) that was not available. When we begin Java EE 8, I would urge you to join the users email list for the project and raise these issues there. Many more experts track that list than the JIRA, and it is easier to have interactive discussions there.

glassfishrobot commented 11 years ago

arjan_t said: I will, thanks again.

glassfishrobot commented 7 years ago

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

glassfishrobot commented 11 years ago

Marked as won't fix on Thursday, January 24th 2013, 12:35:46 pm