-
Bug
-
Resolution: Done
-
Blocker
-
None
It should be possible to lookup a UserTransaction from a node or a cluster and call .begin() with starting the Transaction lazy until the first EJB invocation.
The invocation will implicit begin the transaction and all invocation are sticky to that node.
This is to spread the load across several server instances if there is no running transaction but keep the transaction sticky to the first selected node.
It prevents from a strong affinity to one instance via URI affinity or the necessity to define the node for the UserTransaction upfront.
The sticiness is because of issues with persistence like JPA as here the server is not really 'stateless' as the session of EntityManager can decide to not flush the changed data to the underlying database which can cause issues if the transaction will continued on a different instance if the client invoke EJB's multiple times.
- causes
-
JBEAP-13364 EJB over HTTP always fails with UserTransaction usage
- Closed
- clones
-
WFLY-9282 UserTransaction should be lazy to allow node selection (loadbalancing) even if the invocations stick to one node
- Open
- incorporates
-
JBEAP-12284 [GSS](7.1.0) User can not override with InitialContext properties as expected if wilfdfly-config-xml is used
- Closed
-
JBEAP-13046 Upgrade Transaction client to 1.0.1.Final
- Closed
-
JBEAP-13175 Upgrade JBoss Remoting to 5.0.2.Final
- Closed
-
JBEAP-13176 Upgrade WildFly Naming Client to 1.0.3.Final
- Closed
-
WFLY-9351 Upgrade JBoss EJB Client to 4.0.1.Final (Legacy to 3.0.1.Final)
- Closed
- is documented by
-
JBEAP-13242 Documentation about EJB+transactions in a clustered environment
- Closed
- is incorporated by
-
JBEAP-13178 Upgrade WildFly HTTP client components to 1.0.3.Final
- Closed
- is related to
-
JBEAP-13343 [GSS] JTA based transaction stickiness
- Closed