jakartaee / jakartaee/messaging

Allow a JMSContext or Session to opt out of a Java EE transaction

Open
#130 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

jms21-forreview-major Priority: Major Type: Improvement
Dominant language
Java
Stars
49
Forks
34
PR merge metrics
No merged PRs in 30d

Description

The JMS 2.0 specification, section 12.3 "Behaviour of JMS sessions in the Java EE web or EJB container" states that if a Session or JMSContext is created when there is an active JTA transaction in progress then any session parameters are ignored and the Session or JMSContext will participate in the JTA transaction and will be committed or rolled back when the JTA transaction is committed or rolled back.

The specification doesn't appear to offer any choice as to whether the Session or JMSContext participates in the JTA transaction.

Issue: Should it be possible for the Session or JMSContext to "opt out" of the transaction in some way?

Here are some circumstances in which the JTA transaction might be ignored:

  • If the JMS provider doesn't support XA. The specification is not clear on whether a JMS provider is required to support XA in the Java EE web and EJB containers. In JMS 2.0, section 6.2.8 "Distributed transactions" states that "JMS does not require that a provider support distributed transactions". However this wording dates from JMS 1.1 and it is possible that this statement is intended to apply only to standalone JMS providers which don't support Java EE. This should be clarified.

  • If the connection factory has been configured to not use a JTA transaction. Here are some possible ways in which a conneciton factory might be configured to not use JTA:

    • Using a JMSConnectionFactoryDefinition annotation with the transactional attribute set to false. (The javadocs says that this attribute may be "Set to false if connections should not participate in transactions.
    • Using a connection factory which has been configured in a provider-specific manner to not use JTA transaction.
    • By some standard mechanism, not yet defined, either on the connection factory or the deployment descriptor (see below)
    • By some new parameter to createSession or createContext. (We can't use the existing parameters since these must be ignored in accordance with the EJB 3.1 specification)

If the Session or JMSContext is allowed to opt out of the JTA transaction, then we could define that it behave the same way as a Session or JMSContext that is created when there is no JTA transaction (i.e. only AUTO_ACKNOWLEDGE and DUPS_OK_ACKNOWLEDGE are allowed).

However another possibility is to further extend the specification to allow client-acknowledgement or a local transactions to be used. I think that can be discussed as a separate issue and I have created #131 to cover it.

Affected Versions

[2.0]

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading JMS 2.0 sections 12.3 and 6.2.8, along with the JMSConnectionFactoryDefinition transactional attribute described in the issue. Compare the proposed opt-out mechanisms with related issue #131; done requires a resolved specification decision clarifying whether and how Session or JMSContext can avoid an active JTA transaction.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
api, backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.