The JBoss application server is written to be independent of the actual transaction manager used. JBoss uses the JTA javax.transaction.TransactionManager interface as its view of the server transaction manager. Thus, JBoss may use any transaction manager which implements the JTA TRansactionManager interface. Whenever a transaction manager is used, it is obtained from the well-known JNDI location, java:/TransactionManager. This is the globally available access point for the server transaction manager. If transaction contexts are to be propagated with RMI/JRMP calls, the transaction manager must also implement two simple interfaces for the import and export of transaction propagation contexts (TPCs). The interfaces are transactionPropagationContextImporter and TRansactionPropagationContextFactory, both in the org.jboss.tm package. Being independent of the actual transaction manager used also means JBoss does not specify the format or type of the transaction propagation context used. In JBoss, a TPC is of type Object, and the only requirement is that the TPC must implement the java.io.Serializable interface. When using the RMI/JRMP protocol for remote calls, the TPC is carried as a field in the org.jboss.ejb.plugins.jrmp.client.RemoteMethodInvocation class used to forward remote method invocation requests. Adapting a Transaction Manager to JBossA transaction manager has to implement the JTA to be easily integrated with JBoss. Like almost everything in JBoss, the transaction manager is managed as an MBean. Like all JBoss services, it should implement org.jboss.system.ServiceMBean to ensure proper lifecycle management. The primary requirement of the transaction manager service on startup is that it binds its implementation of the three required interfaces into JNDI. These interfaces and their JNDI locations are as follows:
Establishing these JNDI bindings is all the transaction manager service needs to do to install its implementation as the JBoss server transaction manager. The Default Transaction ManagerJBoss is by default configured to use the fast in-VM transaction manager. This transaction manager is very fast, but does have two limitations:
The corresponding default transaction manager MBean service is the org.jboss.tm.TransactionManagerService MBean. It has four configurable attributes:
org.jboss.tm.XidFactory The XidFactory MBean is a factory for javax.transaction.xa.Xid instances in the form of org.jboss.tm.XidImpl. The XidFactory allows for customization of the XidImpl that it constructs through the following attributes:
UserTransaction SupportThe JTA javax.transaction.UserTransaction interface allows applications to explicitly control transactions. For enterprise session beans that manage transaction themselves (Bean Managed Transactions or BMT), a UserTransaction can be obtained by calling the getUserTransaction method on the bean context object, javax.ejb.SessionContext. The ClientUserTransactionService MBean publishes a UserTransaction implementation under the JNDI name UserTransaction. When the UserTransaction is obtained with a JNDI lookup from an external client, a very simple UserTransaction suitable for thin clients is returned. This UserTransaction implementation only controls the transactions on the server the UserTransaction object was obtained from. Local transactional work done in the client is not done within the transactions started by this UserTransaction object. When a UserTransaction object is obtained by looking up the JNDI name UserTransaction in the same virtual machine as JBoss, a simple interface to the JTA TRansactionManager is returned. This is suitable for web components running in web containers embedded in JBoss. When components are deployed in an embedded web server, the deployer makes a JNDI link from the standard java:comp/UserTransaction Environment Naming Context (ENC) name to the global UserTransaction binding so the web components can look up the UserTransaction instance under the JNDI name as specified by the J2EE. Note For BMT beans, do not obtain the UserTransaction interface using a JNDI lookup. Doing this violates the EJB specification, and the returned UserTransaction object does not have the hooks the EJB container needs to make important checks. |