Transactions Section Index | Page 3
You must set transaction-type in the deployment descriptor.
Yes, but with restrictions. By definition, a stateless session bean has no state; hence, each method invocation must be independent. (The bean can be "swapped out" between method invoc...more
How does an enterprise bean that uses container-managed transactions obtain a JTA UserTransaction object?
It doesn't! By definition, container-managed transaction processing implies that the EJB container is responsible for transaction processing. The session bean has only limited control of transac...more
In some situations, it's necessary for a (stateful) session bean to selectively control which methods participate in transactions, and then take over the bundling of operations that form a logical...more
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 the getUse...more
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 operati...more
How does a client application that employs, say, session beans, obtain a JTA UserTransaction object from the EJB server?
It doesn't. Session beans may obtain a JTA UserTransaction object for method-level bundling of business logic-related operations as a logical unit of work. If a client application must employ JT...more
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,...more
If thread t1 executes UserTransaction.begin() and thread t2 executes UserTransaction.commit(), UserTransaction.rollback(), or any other UserTransaction service, the behavior depends on the (EJB, J...more
What are the ramifications of mixing JTA and non-JTA transactions where the same resources are involved?
It depends on the context/resource. In general, you shouldn't create this type of heterogeneous transaction scenario, especially when working through a Java application server that shares objects...more
A JTS transaction manager must support flat transactions; support of nested transactions is optional. If a client begins a transaction, and within that transaction begins another transaction, the...more
It shouldn't, no matter how clever the programmer! Applets, by definition, should be (very) thin clients. Transaction-related operations should be minimized even in end-user client applications....more
How you gain access to UserTransaction objects varies depending on the type of client. Enterprise JavaBeans provides two types of transaction management: Container-managed transactions. As the ...more
Yes. A JTS transaction manager implements the Java mappings of the CORBA OTS 1.1 specification, specifically, the Java packages org.omg.CosTransactions and org.omg.CosTSPortability. A JTS transa...more
JTS is a specification for implementing a Java transaction manager. A transaction manager serves as an intermediary between an application and one or more transaction-capable resource managers su...more