jms-spec
  1. jms-spec
  2. JMS_SPEC-110

add JMS methods to access an Object's creator: Message.getSession(), Session.getConnection(), ...

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      I know this might be against the API strategy of 'create-and-forget' (Connection creates Session, thereafter only use Session), but in several places it would be convenient to be able to get to an object's creator even after creation.

      For example JMS_SPEC-68 suggests a method Session.acknowledge() to acknowledge() the complete Session instead of a misleading Message.acknowledge(). This is a good change, but within a MessageListener's onMessage(), you have access to the Message only, not the Session

      So to make proper use of Session.acknowledge(), I'm proposing a method Message.getSession() so that inside the onMessage() method you can simply call these, without having to remember the Session object:

      • Message.getSession().acknowledge()
      • Message.getSession().commit()

      Once the API starts down this track, for consistency, it should probably go all the way:
      Session.getConnection(), Connection.getFactory(), ...

        Activity

        axel_podehl created issue -
        Nigel Deakin made changes -
        Field Original Value New Value
        Tags jms21-forreview-minor
        Hide
        Nigel Deakin added a comment -

        This is ultimately a matter of API style. Depending on viewpoint, it's either desirable to be able to navigate "back" to the parent object, or it isn't. There isn't an absolute answer.

        As for Message.getSession(): apart from the issue of whether this is a desirable API style, there is a problem here since the Message may have been created using JMSContext.createMessage() etc. In that case it is inappropriate to request a Session object. (The design of JMSContext deliberately does not have a getSession or getConnection method to keep the classic and simplified APIs separate).

        You make a good point that the session (or context) is not automatically available in a message listener's onMessage, which makes it awkward to commit the local transaction.

        At the time of writing JMS 2.0 has reached the public draft stage. This is not an urgent issue which required incorporation in JMS 2.0, so I will defer it for proper consideration for JMS 2.1. Tagging appropriately.

        Show
        Nigel Deakin added a comment - This is ultimately a matter of API style. Depending on viewpoint, it's either desirable to be able to navigate "back" to the parent object, or it isn't. There isn't an absolute answer. As for Message.getSession() : apart from the issue of whether this is a desirable API style, there is a problem here since the Message may have been created using JMSContext.createMessage() etc. In that case it is inappropriate to request a Session object. (The design of JMSContext deliberately does not have a getSession or getConnection method to keep the classic and simplified APIs separate). You make a good point that the session (or context) is not automatically available in a message listener's onMessage , which makes it awkward to commit the local transaction. At the time of writing JMS 2.0 has reached the public draft stage. This is not an urgent issue which required incorporation in JMS 2.0, so I will defer it for proper consideration for JMS 2.1. Tagging appropriately.
        Hide
        axel_podehl added a comment -

        Yes, agreed. With the new API it's undefined which one to add:

        Message.getSession()

        or

        Message.getJMSContext()

        Since Message can be created from both APIs, it's better to leave this part alone and not add any method to navigate back.

        As for session commit, maybe a Message.commit() - with a clear documentation that this would commit all messages within this session?
        Although that doesn't sound great either...

        Show
        axel_podehl added a comment - Yes, agreed. With the new API it's undefined which one to add: Message.getSession() or Message.getJMSContext() Since Message can be created from both APIs, it's better to leave this part alone and not add any method to navigate back. As for session commit, maybe a Message.commit() - with a clear documentation that this would commit all messages within this session? Although that doesn't sound great either...

          People

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

            Dates

            • Created:
              Updated: