I'd like to propose a modification to this issue:
On 09/08/2011 11:35, Nigel Deakin wrote:
> I have logged the following JIRA issue:
> http://java.net/jira/browse/JMS_SPEC-45
I have updated the description field of this issue to include this proposal.
My previous proposal was to add a new method on Session:
-----------------------------------------------------------------
Session createSession(int sessionMode) throws JMSException
In a normal Java SE environment sessionMode may be set to
Session.AUTO_ACKNOWLEDGE, Session.CLIENT_ACKNOWLEDGE, Session.DUPS_OK_ACKNOWLEDGE
or Session.TRANSACTED
In a Java EE transaction, sessionMode is ignored.
In a Java EE undefined transaction context, sessionMode may be set to
Session.AUTO_ACKNOWLEDGE or Session.DUPS_OK_ACKNOWLEDGE only.
-----------------------------------------------------------------
This proposal appears to have received the tacit approval of the expert group.
However I think an additional simplification would be useful for use in a Java EE environment, where the sessionMode is
in many cases ignored and so the need to supply a value makes the application is an unnecessary complication. I would
therefore like to extend this proposal to add a further new method on Session:
-----------------------------------------------------------------
Session createSession() throws JMSException
This method is particularly intended for use in a Java EE environment,
though it may also be used in a normal Java SE environment.
In a normal Java SE environmentm this is equivalent to calling createSession(Session.AUTO_ACKNOWLEDGE)
In a Java EE transaction, the session will be part of a transaction managed by the container.
In a Java EE undefined transaction context, the session will have a sessionMode of Session.AUTO_ACKNOWLEDGE.
-----------------------------------------------------------------
Any comments?
Separately, John suggested:
> Could your spec change perhaps use an enum to describe the sessionMode as well?
If this has been a new API then an enum would have definitely been the right thing, and my initial reaction was to agree
with John's proposal. However another EG member has pointed out that since we already have four static constants
(Session.AUTO_ACKNOWLEDGE etc) adding four enum values which would effectively duplicate these would unnecessarily
complicate the API. I'm therefore inclined to stick with the existing four static constants. Does anyone else have any
particular views on this?
Nigel