javaee-spec
  1. javaee-spec
  2. JAVAEE_SPEC-8

Portable JNDI name for platform transaction manager

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        ldemichiel added a comment -

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

        Show
        ldemichiel added a comment - This issue was discussed in the expert group, and there were sufficient objections raised against it to not include it.
        Hide
        arjan tijms added a comment -

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

        Show
        arjan tijms added a comment - Just wondering, what was the main objection? The fact that a transaction manager should not be accessible at all, or something else? Thanks!
        Hide
        ldemichiel added a comment -

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

        Show
        ldemichiel added a comment - IIRC, it was seen as compromising the container's ability to manage the transaction context.
        Hide
        arjan tijms added a comment -

        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?)

        Show
        arjan tijms added a comment - 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?)
        Hide
        ldemichiel added a comment -

        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.

        Show
        ldemichiel added a comment - 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.
        Hide
        arjan tijms added a comment -

        I will, thanks again.

        Show
        arjan tijms added a comment - I will, thanks again.

          People

          • Assignee:
            Unassigned
            Reporter:
            arjan tijms
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: