On 30/09/2011 10:49, Ruediger zu Dohna wrote:
> Nigel,
>
> obviously I'm for 2B.
Noted.
>
> Both proposals miss a definition of what would happen in a Java EE undefined transaction context when you pass
> SESSION_TRANSACTED or CLIENT_ACKNOWLEDGE.
This is what I wrote in
http://java.net/jira/browse/JMS_SPEC-45
"...the EJB 3.1 specification, section 13.3.5 does explicitly state that "The Bean Provider should not use the JMS
acknowledge method either within a transaction or within an unspecified transaction context. Message acknowledgment in
an unspecified transaction context is handled by the container.
"It is curious that although Session.acknowledge is prohibited in a unspecified transaction context, Session.commit is
not, even though both perform message acknowledgement. If the former is invalid, then the latter must be as well.
"This means that within an unspecified transaction context:
* a non-transacted session using client acknowledgement is explicitly prohibited
* a(local) transacted session is implicitly prohibited
* a non-transacted session is permitted, with both client-acknowledgement and dups-ok-acknowledgement (which is an
optimised version of auto-acknowledgement) allowed."
We could add this to the JMS spec as clarification.
> 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.
Recap: this is my current proposal in
http://java.net/jira/browse/JMS_SPEC-45
"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."
In a Java EE transaction, since sessionMode is always ignored, we could throw an exception if this method is called in a
transaction. This would force people to use the no-arg version. They have no choice, so why do they need an argument?
In a Java EE undefined transaction context, since sessionMode may only be set to Session.AUTO_ACKNOWLEDGE or
Session.DUPS_OK_ACKNOWLEDGE, we could throw an exception if sessionMode was Session.TRANSACTED or
Session.CLIENT_ACKNOWLEDGE.
(views please)
> I'd prefer to have then also an exception thrown,
> if the mode is not SESSION_TRANSACTED.
This all depends on whether we think SESSION_TRANSACTED covers XA transactions as well as local transactions. I think we
should keep these separate, otherwise we will cause confusion in the SE case.
I'm not sure we should add a new SESSION_XA option (which would throw an exception in SE), That is potentially confusing
since people might expect it to return a XASession - which it would not.
Also, we don't want to give the misleading impression that in a Java EE transaction the user has can specify through
method arguments whether the session has a XA transaction or not. Currently the EJB spec is pretty clear that they
don't. Whether there is a XA transaction is specified using CMT/BMT configuration.
(It's remarkable how poorly-defined, ambiguous and inconsistent this corner of Java EE is at the moment. That's why
we're having difficulty clarifying it)
Nigel
>
>
> 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
>>
>>
>>
>>