Nigel,
obviously I'm for 2B.
Both proposals miss a definition of what would happen in a Java EE
undefined transaction context when you pass SESSION_TRANSACTED or
CLIENT_ACKNOWLEDGE. I think an exception would be appropriate, but I'd
even go one step further and not ignore the session mode when there is a
transaction available. I'd prefer to have then also an exception thrown,
if the mode is not SESSION_TRANSACTED.
Rüdiger
On 29.09.2011 12:22, Nigel Deakin wrote:
> So, the proposals on this issue stand as follows:
>
> 1. A new method on Connection with no arguments as follows:
>
> -----------------------------------------------------------------
> 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.
> -----------------------------------------------------------------
>
> 2. In addition, a new method on Connection with a single argument. There
> are two alternatives:
>
> Option 2A (proposed by Nigel)
> -----------------------------------------------------------------
> 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.
> -----------------------------------------------------------------
>
> Option 2B (proposed by Ruediger and John)
> -----------------------------------------------------------------
> Session createSession(SessionMode sessionMode) throws JMSException
>
> In a normal Java SE environment sessionMode may be set to
> SessionMode.AUTO_ACKNOWLEDGE, SessionMode.CLIENT_ACKNOWLEDGE,
> SessionMode.DUPS_OK_ACKNOWLEDGE
> or SessionMode.TRANSACTED
>
> In a Java EE transaction, sessionMode is ignored.
>
> In a Java EE undefined transaction context, sessionMode may be set to
> SessionMode.AUTO_ACKNOWLEDGE or SessionMode.DUPS_OK_ACKNOWLEDGE only.
> -----------------------------------------------------------------
>
> 3. The existing createSession with two arguments would remain unchanged
>
>
> From the responses received so far, I think there is general consensus
> support for (1). However I do need views on whether you prefer (2A) or
> (2B).
>
> My own preference is for (2A). No doubt if the spec had been written
> subsequent to Java 5 it would have used enums. However it wasn't and JMS
> has used these four integer constants for many years and people have
> been using them without any problem. Introducing a set of enums to
> specify exactly the same thing as these existing constants simply adds
> complication and potential confusion to solve a non-existent problem.
>
> But please do give your views.
>
> Nigel
>
>
>
>