Dear expert group,
This email is, as usual, addressed at the expert group and subscribers to the user alias. However I'd particularly like
to address it to those who develop JMS implementations. (You know who you are :-)
I refer to this JIRA issue:
http://java.net/jira/browse/JMS_SPEC-45
We've discussed this before, and I'm now revisiting this issue with the intention of drafting suitable changes to the
spec and javadocs, and in proposing suitable clarifications to propose to the EJB 3.2 spec.
Please read that issue for a reminder of the this issue.
That issue explains that createSession() has two arguments when it really should have only one, or even none. However
we've already discussed what to do about that and I'm not concerned about that right now.
My area of particular concern today is the behaviour of connection.createSession in various Java EE scenarios. This is
described in two sections of the EJB 3.1 specification: section 13.3.5 "use of JMS APIs in Transactions" and section
13.6.5 "Handling of Methods that run with an unspecified transaction context". As my analysis in that issue explains,
these sections are not very clear and leave several questions unanswered.
I think we should attempt to clarify this for JMS 2.0 and EJB 3.2, in the javadoc for createSession and also elsewhere.
However there is a danger that if we attempt to "clarify" something which is currently underfined, ambiguous or unclear
in the spec we may unwittingly cause JMS providers to change the way they behave in a way which will cause existing
applications to behave differently.
So I'd like to ask all the JMS vendors out there: how does *your* JMS provider interpret these two sections of the EJB
spec? (Note that the Java EE spec states that they applies to the web container too).
Here are some of the questions I think JMS vendors need to be able to answer, but which are not unambiguously answered
in the EJB spec:
---------------------------------------------------------------------------------------------------
1. Does section 13.3.5 "use of JMS APIs in Transactions" (which states that the arguments to createSession() are ignored
in a transaction) apply to BMT transactions as well as CMT transactions?
2. Does 13.6.5 "Handling of Methods that run with an unspecified transaction context" apply in every case where there
isn't an active JTA transaction, such as the BMT case before userTransaction.begin() is called, or in the CMT case when
the transactional attribute is NEVER?
3. Do the above two cases cover all scenarios, or are there other cases to which neither applies?
4. Section 13.3.5 "use of JMS APIs in Transactions" states "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.".
4a Why is this?
4b What does your JMS provider do if acknowledge() is called in such a case?
4c Is session.commit() also forbodden, given that this also performs message acknowledgement?
5. In a BMT application, what happens if the session is created *before* the transaction is started? Consider the following:
Session session=connection.createSession(false,Session.AUTO_ACKNOWLEDGE);
MessageProducer producer = session.createProducer(destination);
producer.send(message1);
userTransaction.begin();
producer.send(message2);
. . .
userTransaction.commit();
Is this valid? Is message1 sent immediately or is it committed as part of the user transaction? Is message2 sent
immediately or is it committed as part of the user transaction?
---------------------------------------------------------------------------------------------------
There are no doubt other other cases which are unclear as well, but this would be a useful start.
Thanks,
Nigel
Nigel