-
Feature Request
-
Resolution: Obsolete
-
Major
-
None
-
None
-
None
----------------------------------------------------------------------
Why does the customer need this? (List the business requirements here)
----------------------------------------------------------------------
We cannot afford an additional unnecessary resource enlisted on the caller side when calling a SSEJB through its remote interface, when this SSEJB makes no use of the caller transaction anyway (e.g. it uses a TransactionAttribute RequiresNew). Indeed, this typically makes the caller's transaction go 2PC, with at least the below negative consequences:
1. A potential performance hit on the client because the other client resource needs to go through a full 2PC completion sequence prepare + commit, while a One Phase Commit Optimisation would have been sufficient
2. More importantly, it makes client transaction completion depend on the painful asynchronous XA recovery mechanism in case something goes wrong in the 2PC. The asynchronous nature of this recovery can even have devastating effects: think for example of a single-threaded MDB dequeuing and enqueuing messages (against the same resource), with the requirement that messages must be processed in order. An asynchronous (delayed) transaction completion can cause ordering inconsistency.
3. Not to mention resources that do not actually support 2PC but still implement the XA interface (this is for example mandated by the JMS/JCA specs. for transacted inflow messaging) - those might shout (even fail?) upon being asked to prepare().
------------------------------------------------------------------------------------
How would the customer like to achieve this? (List the functional requirements here)
------------------------------------------------------------------------------------
We would like an optimization by which, if the EJB called does nothing with the caller's transaction (e.g. the EJB uses a TransactionAttribute RequiresNew), then no additional resource is enlisted on the caller's side.
This is already described by RedHat in discussion [1]/[2].
[1] http://lists.jboss.org/pipermail/wildfly-dev/2016-January/004725.html
[2] http://lists.jboss.org/pipermail/wildfly-dev/2016-February/thread.html
------------------------------------------------------------------------------------------------------
Does the customer have any specific timeline dependencies and which release would they like to target?
------------------------------------------------------------------------------------------------------
No specific timeline dependency.
- is caused by
-
WFLY-7860 Only import transactions lazily
- Closed
- is related to
-
JBEAP-225 Calling EJB with "REQUIRES_NEW" transaction attribute creates two transactions aka Omit no-op transaction if lifecycle method is missing
- Closed
- relates to
-
WFLY-4608 Omit no-op transaction if lifecycle method is missing
- Closed
-
JBEAP-5448 Enhance behavior of transaction propagation called over IIOP to not start 2PC when called ejb creates own new transaction
- Closed
-
WFLY-6920 Enhance behavior of transaction propagation called over IIOP to not start 2PC when called ejb creates own new transaction
- Open