jaikiran pai [
https://community.jboss.org/people/jaikiran] modified the document:
"Remote EJB distributed transactions and recovery"
To view the document, visit:
https://community.jboss.org/docs/DOC-48398
--------------------------------------------------------------
h1. Overview
Unlike previous JBoss AS versions, remote transaction propagation between 2 server
instances for EJB invocations does *not* require JTS. EJB client API which was introduced
in AS7 uses its own protocol for remote transaction propagation between the client and the
server for EJB invocations.
h1. Typical scenario
Let's consider an EJB A hosted on Server 1 and EJB B hosted on Server 2. EJBs are
transactional by default. There are ways to disable transactions on EJBs or certain
business methods of EJBs. But we won't be going into that part, in this article
because our intention is to focus on the transaction propagation and recovery for EJBs,
which obviously will require transactional EJBs.
When a client, for example a standalone Java application, invokes on EJB A (on Server 1) a
transaction is created. Later, during that invocation request, if EJB A in turn invokes on
EJB B (on Server 2), the transaction propagation is carried out between the servers
hosting those 2 EJBs. Previous versions of JBoss AS require JTS for the transaction
propagation to happen. However in AS7 we have a JBoss specific protocol implemented in EJB
client API which does the necessary propagation. The EJB client API interacts with the
transaction manager on Server 1 and Server 2 to carry out the necessary transaction
propagation and management. Furthermore on the server side of the interaction (i.e. of
Server 2 in this case), the AS7 EJB integration layer (heavily) uses JBoss Transaction
project (Narayana) APIs to import the remote transaction and further manage it.
h1. Crash and transaction recovery
JBoss Transactions (Narayana) project provides the necessary API infrastructure for
libraries like the EJB client API project to integrate for transaction recovery in case of
client/server crash scenarios. The design of that API is explained in the JBoss
Transactions project manual here
http://docs.jboss.org/jbosstm/4.17.3.Final/guides/failure_recovery_guide/
http://docs.jboss.org/jbosstm/4.17.3.Final/guides/failure_recovery_guide/.
From a EJB client API perspective, a org.jboss.tm.XAResourceRecovery
implementation needs to be registered against the transaction subsystem's recovery
manager service. This implementation of XAResourceRecovery is responsible for returning
instances of XAResource(s) when the getXAResources() method is invoked by the recovery
manager on that implementation. The returned XAResource(s) will then be used by the
recovery manager to invoke the:
/**
* Obtains a list of prepared transaction branches from a resource manager. The
transaction manager calls this method
* during recovery to obtain the list of transaction branches that are currently in
prepared or heuristically completed states.
*/
javax.transaction.xa.Xid[] recover(int i) throws javax.transaction.xa.XAException;
As is evident from the name of the method, the implementation is responsible for returning
the Xid(s) which need to be recovered.
h1. XAResourceRecovery implementation for EJB client API
As explained in the JBoss Transactions document, the recovery process involves a
background thread which runs at periodic intervals to check for transactions that should
be recovered. From a EJB client API perspective, it has to know the target server against
which it is issuing a recover request and also the node identifier of the node/server on
which the (previously run) transaction(s) originated.
h2. Node identifier of the transaction origin
This is also known as the "parent node name". This is the node on which the
transaction, which was propagated, originated. The transaction subsystem integration in
AS7 exposes this node identifier via the CoreEnvironmentService:
package org.jboss.as.txn.service;
public class CoreEnvironmentService implements Service<CoreEnvironmentBean> {
...
}
package com.arjuna.ats.arjuna.common;
public class CoreEnvironmentBean implements CoreEnvironmentBeanMBean {
....
public String getNodeIdentifier() {
return nodeIdentifier;
}
So it's straightforward for the EJB client integration in AS7 to know what the node
identifier of itself.
h2. Target server(s)/EJBReceiver(s) against which the recover request has to be issued
The EJBClientContext can potentially contain numerous EJBReceiver(s), each of which
correspond to a different node. Furthermore, the EJBReceiver(s) within a EJBClientContext
can be dynamic - which means at it may not always contain the same set of EJBReceiver(s).
Certain receivers may be added or removed as and when such a need arises. As such,
there's no fixed set of EJBReceiver(s) which the EJBClientContext can known before
hand to issue the recovery request against. So how does the EJB client API know which
EJBReceiver(s) should it issue the recovery request when the recovery manager background
process asks it for the Xid[] that need to be recovered.
The answer to that question is that whenever a EJBReceiver is registered in a
EJBClientContext, it will make that EJBReceiver eligible for issuing a recovery request
against. This is a very important thing to remember since if a server/EJBReceiver was
being used during EJB invocations and either the server or client crashed, then the
recovery against the server/EJBReceiver will not be triggered unless that EJBReceiver gets
registered within a EJBClientContext. This however isn't a restriction since a
recovery process between 2 servers only makes sense when they are communicating with each
other and from a EJB client API perspective, the communication can only happen when the
EJBReceiver is registered in a EJBClientContext.
--------------------------------------------------------------
Comment by going to Community
[
https://community.jboss.org/docs/DOC-48398]
Create a new document in JBoss AS 7 Development at Community
[
https://community.jboss.org/choose-container!input.jspa?contentType=102&a...]