Nigel,
On 30.09.2011 12:48, Nigel Deakin wrote:
> 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?
Maybe they want to make sure that there _is_ a transaction
(SESSION_TRANSACTED) or that there is none (AUTO_ACKNOWLEDGE). But it
probably would be better to annotate the method as transaction REQUIRED
or NEVER resp.
> 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)
This is exactly what I meant.
> > 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.
I think we should keep XA transactions out of the scope of the JMS APIs,
just as they are right now.
> (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)
(+1! We recently had a lot of fun tracking down a bug because
transaction distribution did or did not work, depending on which node a
load balanced EJB call was directed to.)
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
>>>
>>>
>>>
>>>
>
>