21.Can different threads manipulate the same transaction?

If thread t1 executes UserTransaction.begin() and thread t2 executesUserTransaction.commit(), UserTransaction.rollback(), or any otherUserTransaction service, the behavior depends on the (EJB, JMS, or whatever) server's transaction support as well as the transaction manager implementation.

22.Can a servlet maintain a JTA UserTransaction object across multiple servlet invocations?

No. A JTA transaction must start and finish within a single invocation (of the service() method). Note that this question does not address servlets that maintain and manipulate JDBC connections, including a connection's transaction handling.

23.Why would a client application use JTA transactions?

One possible example would be a scenario in which a client needs to employ two (or more) session beans, where each session bean is deployed on a different EJB server and each bean performs operations against external resources (for example, a database) and/or is managing one or more entity beans. In this scenario, the client's logic could required an all-or-nothing guarantee for the operations performed by the session beans; hence, the session bean usage could be bundled together with a JTA UserTransactionobject.
In the previous scenario, however, the client application developer should address the question of whether or not it would be better to encapsulate these operations in yet another session bean, and allow the session bean to handle the transactions via the EJB container. In general, lightweight clients are easier to maintain than heavyweight clients. Also, EJB environments are ideally suited for transaction management.

24.How does a session bean obtain a JTA UserTransactionobject?

If it's necessary to engage in explicit transaction management, a session bean can be designed for bean-managed transactions and obtain a UserTransaction object via the EJBContext using thegetUserTransaction() method. (It may also use JNDI directly, but it's simpler to use this convenience method.)

25.How does a client use the javax.transaction package?

Typically, a client that needs to perform multiple operations within a transactional unit simply obtains a UserTransaction object and uses its services. These services include:
• begin()
• commit()
• getStatus()
• rollback()
• setRollbackOnly()
• setTransactionTimeout()
In addition, of course, the client must deal with exceptions such asNotSupportedException, RollbackException, and others, and potentially, the status codes defined in the Status interface.
The following interfaces prescribe services that are used by application servers, for example, an EJB server, in communicating with and requesting services from a JTS transaction manager:
• Synchronization
• Transaction
• TransactionManager
In general, there is no reason for a client to use these three interfaces. When an application employs these services, it has, by definition, crossed the line from client to application server. Middleware (application servers) exist for a reason, primarily to serve as an intermediary between lightweight clients and dedicated servers, for example, a database server. If a client needs the services of a JTS transaction manager, and these services are not provided by an existing application server, the client probably needs to be factored into a thin client(s) plus an application server. That is, the distributed application needs to implement a custom application server that insulates distributed clients from low-level transactional details.

26.How does a client use the javax.jts package?

Clients do not use this package. This package prescribes functionality that is implemented by JTS transaction managers.

27.How does a client use the javax.transaction.xa package?

Clients do not use this package. This package prescribes functionality that is used by JTS transaction managers when managing global transactions involving one or more resources such as database servers, JMS servers, and others.

28.What is two-phase commit?

A commit operation is, by definition, an all-or-nothing affair. If a series of operations bound as a transaction cannot be completed, the rollback must restore the system (or cooperating systems) to the pre-transaction state.
In order to ensure that a transaction can be rolled back, a software system typically logs each operation, including the commit operation itself. A transaction/recovery manager uses the log records to undo (and possibly redo) a partially completed transaction.
When a transaction involves multiple distributed resources, for example, a database server on each of two different network hosts, the commit process is somewhat complex because the transaction includes operations that span two distinct software systems, each with its own resource manager, log records, and so on. (In this case, the distributed resources are the database servers.)
Two-phase commit is a transaction protocol designed for the complications that arise with distributed resource managers. With a two-phase commit protocol, the distributed transaction manager employs a coordinator to manage the individual resource managers.
The commit process proceeds as follows:
• Phase 1
o Each participating resource manager coordinates local operations and forces all log records out:
o If successful, respond "OK"
o If unsuccessful, either allow a time-out or respond "OOPS"
• Phase 2
o If all participants respond "OK":
 Coordinator instructs participating resource managers to "COMMIT"
 Participants complete operation writing the log record for the commit
o Otherwise:
 Coordinator instructs participating resource managers to "ROLLBACK"
 Participants complete their respective local undos
In order for the scheme to work reliably, both the coordinator and the participating resource managers independently must be able to guarantee proper completion, including any necessary restart/redo operations. The algorithms for guaranteeing success by handling failures at any stage are provided in advanced database texts.

29.How can I manage long duration transactions?

By saying "how do I manage" it seems like you are doing bean-managed transaction using the javax.transaction.UserTransactioninterface to explicitly demarcate the transaction boundaries. In EJB 1.1 you can do that with a session bean. (With the upcoming 2.0 specification, you can also do it with message beans!)

In the case of a stateful session bean, the EJB specification allows the transaction boundary to be maintained over multiple method calls i.e., the bean method is not required to commit a transaction at the end of a business method (unlike stateless session beans). You could therefore achieve the effect of a long transaction over the entire use-case that the session bean implements. It is possible for the bean to open and close database connections for each method instead of holding it over the entire use-case. See the code example in the EJB 2.0 (Draft) Specification Section 16.4.3 Enterprise Beans Using Bean Managed Transaction Demarcation.

30.?

31.?

32.?

33.?

34.?

35.?

36.?

37.?

38.?

39.?

40.?