org.objectweb.jotm.JOTMArchitecture.html Maven / Gradle / Ivy
Show all versions of jotm-core Show documentation
JOTM Architecture
JOTM Architecture
$Revision: 1.1 $ $Date: 2003-12-17 23:22:41 $
JOTM design is very similar to OTS specification (JOTM
started as an OTS implementation).
However, it is not an implementation of OTS and several parts of its
design changed significantly from OTS.
JOTM core interfaces are very similar to OTS (most changes are the
type of exception being thrown, RemoteException for JOTM interfaces to
conform to RMI):
- Control
- Terminator
- Coordinator
- RemoteSynchro (equivalent
to OTS Synchronization)
- TransactionFactory
- TransactionContext
- Resource
In addition JOTM depends on JTA interfaces:
The most confusing aspect of JOTM is the use of both Resource and
XAResource interfaces at different level in the code.
This comes from the way JOTM handles distribution and deals
with resource managers (RDBMS, MOM, EIS,...)
Communicating with Resource Managers
JOTM relies only on XAResource objects to deal with Resource Managers.
All systems supporting distributed transactions (JDBC, JMS, J2EE
Connectors) do so by providing an implementation of XAResource
interface.
Thus, the transaction manager can treat the different resource
managers uniformally through the use of the XAResource.
Distributed communication
However, XAResource is not a remote interface and can't be access
through RMI.
So if the transaction is using XAResources located on different JVM,
JOTM can't directly use XAResources. It need a way to communicate
remotely with them.
Enter the Resource interface.
The Resource interface is almost identical to OTS
Resource interface
(it only adds RemoteException throwing to method signatures).
JOTM communicates remotely with the different XAResources using
Resource objects.
In fact, one Resource object is used to communicate with the
different XAResource on a given JVM.
To sum up:
- JOTM handles local Resource Managers
through
XAResource
objects.
- JOTM handles remote XAResources through
Resource
objects
"Remote 2PC" and "Local 2PC"
A quick look at JOTM classes highlights the presence of the same
methods (prepare/commit/rollback or variations like doPrepare and so
on) in different objects with no clear relations between them.
Such objects are:
ControlImpl (implements Terminator
and Resource)Current (implements UserTransaction
and TransactionManager)SubCoordinator (implements Resource)TransactionImpl (implements Transaction)XAResource
There is a strict hierarchy between these objects as they are all
involved in the 2 Phace Commit but at different level:
- Initiators of the 2PC :
Current and
TransactionImpl
- Manager of the remote 2PC :
ControlImpl
- Manager of the local 2PC :
SubCoordinator
- Resource Managers :
XAResource
Class Description
Current
- implements
UserTransaction and TransactionManager
- associates the current thread with the correct
transaction
- used to demarcate the transaction (
begin,
[commit,rollback])
TransactionImpl
- used to terminate the transaction
- using its transaction context, this object knows if the transaction
is only local (all
XAResource are in the same JVM) or distributed
(XAResources in different JVMs)
SubCoordinator
- implements
Resource
- handles 2PC of its local
XAResources
ControlImpl
- implement
Terminator
- handles 2PC of its remote
Resources (mostly implemented by
SubCoordinator)
XAResource
- represents a Resource Manager involved in a transaction
2 Phase Commit Engine
How is the JOTM 2PC engine designed?
Which bjects are involved in a 2PC?
- Completion is started by
Current.commit()
Current delegates commit() to the Transaction object
associated with the current thread (represented by
TransactionImpl).- If the transaction is only local (no remote
Resource)
SubCoordinator manages the local 2PC and its
XAResources
- else
ControlImpl calls prepare() on its Resources
(i.e. SubCoordinators)
- each
SubCoordinator calls prepare() on its
XAResources and returns the
overall vote to ControlImpl
- if all
ControlImpl's Resource
voted OK (i.e all
SubCoordinators' XAResources voted
XA_OK)
ControlImpl calls commit() on its Resources
- each
SubCoordinators calls commit() on its
XAResources
- else
ControlImpl calls rollback() on its Resources
- each
SubCoordinators calls rollback() on its
XAResources
It is to be noted that a local transaction can be seen as an
optimization of a distributed transaction with only one remote
Resource which happens to be in the same JVM.
So we can avoid the remote call to ControlImpl and just call
SubCoordinator_commit_one_phase() (this method
corresponds to the remote 1PC but it will handle the local 2PC with the local
XAResources.
The hierarchy of call on the objects during the 2PC is:
Current
\
TransactionImpl
\
ControlImpl
// skipped if transaction is local.
// manage 2PC on remote Resources.
\
SubCoordinator
// local transaction.
// manage 2PC on local XAResources.
\
XAResource