[JMS_SPEC-110] add JMS methods to access an Object's creator: Message.getSession(), Session.getConnection(), ... Created: 08/Jan/13 Updated: 09/Jan/13
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
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:
Once the API starts down this track, for consistency, it should probably go all the way:
|Comment by Nigel Deakin [ 09/Jan/13 ]|
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.
|Comment by axel_podehl [ 09/Jan/13 ]|
Yes, agreed. With the new API it's undefined which one to add:
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?