Lightweight Clients with Delegated Commit Client-initiated Transactions Transaction Integrity

5-2 Programming JTA for Oracle WebLogic Server ■ Section 5.2.5, Flat Transactions ■ Section 5.2.6, Relationship of the Transaction Service to Transaction Processing ■ Section 5.2.7, Multithreaded Transaction Client Support ■ Section 5.2.12, General Constraints These sections describe the capabilities and limitations of the Transaction Service that supports EJB and RMI applications:

5.2.1 Lightweight Clients with Delegated Commit

A lightweight client runs on a single-user, unmanaged desktop system that has irregular availability. Owners may turn their desktop systems off when they are not in use. These single-user, unmanaged desktop systems should not be required to perform network functions such as transaction coordination. In particular, unmanaged systems should not be responsible for ensuring atomicity, consistency, isolation, and durability ACID properties across failures for transactions involving server resources. WebLogic Server remote clients are lightweight clients. The Transaction Service allows lightweight clients to do a delegated commit, which means that the Transaction Service allows lightweight clients to begin and terminate transactions while the responsibility for transaction coordination is delegated to a transaction manager running on a server machine. Client applications do not require a local transaction server. The remote implementation of UserTransaction that EJB or RMI clients use delegates the actual responsibility of transaction coordination to the transaction manager on the server.

5.2.2 Client-initiated Transactions

A client, such as an applet, can obtain a reference to the UserTransaction and TransactionManager objects using JNDI. A client can begin a transaction using either object reference. To get the Transaction object for the current thread, the client program must invoke the TransactionManagertm.getTransaction method.

5.2.3 Transaction Integrity

Checked transaction behavior provides transaction integrity by guaranteeing that a commit does not succeed unless all transactional objects involved in the transaction have completed the processing of their transactional requests. The Transaction Service provides checked transaction behavior that is equivalent to that provided by the requestresponse inter-process communication models defined by The Open Group.

5.2.4 Transaction Termination