Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1067053 - [Doc Bug Fix] Incorrect facts about JTA transaction context distribution
Summary: [Doc Bug Fix] Incorrect facts about JTA transaction context distribution
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Documentation
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: post-GA
: EAP 6.4.3
Assignee: Nidhi
QA Contact: Russell Dickenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-19 15:09 UTC by Ondrej Chaloupka
Modified: 2015-10-20 12:45 UTC (History)
3 users (show)

Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Build Name: 22508, Administration and Configuration Guide-6.3-1 Build Date: 03-02-2014 14:00:41 Topic ID: 4316-563375 [Latest]
Last Closed: 2015-10-20 12:45:58 UTC
Type: Bug


Attachments (Terms of Use)

Description Ondrej Chaloupka 2014-02-19 15:09:15 UTC
Title: JTA Clustering Limitations
(or Limitations on JTA transactions see below)

The section about JTA clustering limitations is incorrect.

There is already processed bugzilla which put the wording in correct way:
https://bugzilla.redhat.com/show_bug.cgi?id=1035553
and changes title to: Limitations on JTA transactions

But the fact is that the JTA transaction supports to be distributed along the EJB remote call. Put it in other words the transaction context is passed along the ejb remote calls including the jta transactions.

There is just one limitation which is mentioned in this bz:
https://bugzilla.redhat.com/show_bug.cgi?id=952746

In case of recovery it's needed to reconnect the remote server by some ejb call. The recovery launch for both servers automatically as it's in case of jts. But when some ejb remote call passes then the recovery is triggered.

This is explanation from Jaikiran Pai the ex-developer on ejb remoting:
When a connection breaks down between the server and the client, specifically when the client goes down and comes back up again, then the server and the client will not auto communicate with each other. 
In other words, the server will have no knowledge (in EJB resource sense) that the client has come back up again. 
That effectively means that the EJB tx recovery process will have no clue of the EJB nodes to communicate with.
To deal with that, there should be some communication from the client (which is now up) to the server to reestablish that connection. 
In a real application, it would be the first invocation from the client to the server.

Comment 2 Ondrej Chaloupka 2015-09-01 09:31:32 UTC
Hi Nidhi,

as I'm aware of the status in EAP 6.4. There is a limitationof JTA transactions and in their ability of transaction context distribution. Current section says:
" JTA transactions cannot be distribution aware across multiple instances of JBoss EAP 6. For this behavior, use JTS transactions.
To use JTS transactions, you need to configure the ORB, which includes enabling transactions in the JacORB subsystem, then configure the JTS subsystem."

I would propose to be reworded to something like

"JTA transactions are not fully transaction distribution aware across multiple instances of JBoss EAP 6. 
In current implementation the transaction context is passed along the remote ejb calls but this works only for simple scenarios where one server calls another one. If there are more servers joint to the transaction distribution the context propagation is not fully safe.
For full transaction distribution support behavior, use JTS transactions.
To use JTS transactions, you need to configure the ORB, which includes enabling transactions in the JacORB subsystem, then configure the Transaction subsystem to use JTS transactions. Plus ejb needs to be called with use of IIOP protocol."

Ondra

Comment 6 Ondrej Chaloupka 2015-09-29 10:16:08 UTC
Nice, thank you!


Note You need to log in before you can comment on or make changes to this bug.