Transactions Faq From Jguru

Transactions FAQ From jGuru Generated Sep 13, 2005 2:24:18 PM Location: http://www.jguru.com/faq/Transactions Ownership: http://www.jguru.com/misc/user-agree.jsp#ownership. What is a transaction? Location: http://www.jguru.com/faq/view.jsp?EID=2555 Created: Dec 14, 1999 Modified: 1999-12-14 12:34:25.051 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) A transaction is an abstraction of an atomic and reliable execution sequence. Transaction processing is important for almost all modern computing environments that support concurrent processing. In a distributed computing environment, if, for example, multiple clients were to interact with the same database table concurrently, it's possible that interleaved database operations could leave the table in an inconsistent state. Transaction support is also important because systems can fail at any point in an execution sequence. If, for example, a database update operation involves several dependent tables, and the computer system fails when the database update is only partially completed, the database could be left in an inconsistent, even inoperable, state. File and database processing were essential operations with early multiprocessing computing systems; hence, transaction processing was necessary to guarantee their integrity. In today's complex distributed environments, transactions are fundamental to many distributed operations, for example, guaranteed delivery and ordering of a series of messages exchanged between two distributed application components. In this scenario, the message exchange should take place within an atomic execution sequence. During an atomic execution sequence a concurrency control algorithm manages interleaved operations to achieve the same effect as executing those operations in serial order. This algorithm includes, or calls on, a recovery algorithm that provides the logic necessary to undo and/or redo partially completed operations, depending on the execution context. Concurrency control and recovery algorithms are based in part on serializability theory. What is a distributed transaction? Location: http://www.jguru.com/faq/view.jsp?EID=2559 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) A distributed transaction bundles multiple operations in which at least two network hosts are involved, for example, an enterprise bean deployed under an Enterprise JavaBean (EJB) server on network host jupiter that has a JDBC connection(s) to a database server on network host saturn. In enterprise computing, it's often the case

that several network hosts are involved, each hosting different servers, for example, web servers, EJB servers, Java Message Service (JMS) servers, and other Java or CORBA-based application servers. In order to satisfy a client's dependence on an all-or-nothing guarantee for a sequence of operations, a transaction manager is responsible for creating and managing a global transaction that encompasses all operations against the implied resources. The transaction manager accesses each resource, for example, a relational database system, through the respective resource manager. What is the acronym ACID? Location: http://www.jguru.com/faq/view.jsp?EID=2560 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) ACID represents the four properties of every transaction: • • • •

Atomicity - Either all of the operations bundled in the transaction are performed successfully or none of them are performed. Consistency - The transaction must leave any and all datastores that are affected by the transaction in a consistent state. Isolation - From the application's perspective, the current transaction is independent, in terms of application logic, from all other transactions running concurrently. Durability - The transaction's operations against a datastore must persist.

What parties are involved in transaction processing? Location: http://www.jguru.com/faq/view.jsp?EID=2561 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) There are five principals: • • • • •

One or more client applications - optionally initiate client-based transactions One or more application servers - initiate transactions on behalf of clients The transaction manager - the intermediary between the clients and/or application server and the distributed transaction functionality One or more resource managers - for service access to external resources A communication resource manager - for propagation of transaction contexts

What is the Java Transaction API (JTA)? Location: http://www.jguru.com/faq/view.jsp?EID=2562 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) JTA is a service-oriented API specification. Typically, we think of JTA as the service API used by application programmers to group operations into one or more logical transactions. JTA actually provides three types of services: •

Transactional operations in client applications

• •

Transactional operations in application servers performed on behalf of clients Global transactional management in a Java transaction manager coordinating multiple transaction-capable resource managers such as database servers and messaging systems

The most noticeable and often-used functionality is javax.transaction.UserTransaction, which provides services for explicit client control of transactions. What is the Java Transaction Service (JTS)? Location: http://www.jguru.com/faq/view.jsp?EID=2563 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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 such as database servers and messaging systems. The JTS specification encompasses the JTA API specification. Comments and alternative answers

What is the difference between JTA and JTS? When must... Author: Saryu Mehta (http://www.jguru.com/guru/viewbio.jsp?EID=264323), Dec 11, 2000 What is the difference between JTA and JTS? When must I go for JTS rather than JTA? Re: What is the difference between JTA and JTS? When must... Author: kirupakaran jayaraman (http://www.jguru.com/guru/viewbio.jsp?EID=387804), Mar 26, 2001 JTS- (Java Transaction service) It's a service offered by various APPLICATION SERVERS as mentioned in J2EE specifications. It's simplpy the the in-built support given to reduce the burden of programmers hardcoding the entire transaction logics (related to low level problems like network problems) And JTA - Java Transaction API is one such implementation of JTS specification prepared by sun microsystems. This API includes 1. javax.transaction.Status 2. javax.transaction.Transaction 3. javax.transaction.TransactionManager 4. javax.transaction.UserTransaction 5. javax.transaction.xa.Xid 6. javax.transaction.xa.XAResourse 7. javax.transaction.Synchronisation any queries mail to [email protected] bye kirupa Re: What is the difference between JTA and JTS? When must... Author: bony boy (http://www.jguru.com/guru/viewbio.jsp?EID=408041), Apr 22, 2001 JTA is an API and JTS is an implementation(will be done by EJB Server vendors) of the API . Re[2]: What is the difference between JTA and JTS? When must...

Author: Krishma Singla (http://www.jguru.com/guru/viewbio.jsp?EID=1183951), Jul 6, 2004 I find it contradictory to Kirupa Re[2]: What is the difference between JTA and JTS? When must... Author: sandeep kumar (http://www.jguru.com/guru/viewbio.jsp?EID=1225718), Feb 7, 2005 The JavaTM2 Platform, Enterprise Edition (J2EE) simplifies application programming for distributed transaction management. J2EE includes support for distributed transactions through two specifications, Java Transaction API (JTA) and Java Transaction Service (JTS). The JTA is a high level API that allows applications and application servers to access transactions. The JTA defines a high-level transaction managementspecification intended for resource managers and transactional applications in distributed transaction systems. The JTS specifies the implementation of a Transaction Manager, which supports JTA and implements the Java mapping of the OMG ObjectTransaction Service (OTS) 1.1 specification at the level below the API. It is theJTS that is responsible for managing the interoperability of transactions between platforms. JTS vs MTS Author: Hrishikesh Srivatsa (http://www.jguru.com/guru/viewbio.jsp?EID=742668), Jan 31, 2002 Can we compare MTS and JTS ? JTS is a specification for the Transaction Manager and will be a vendor specific implementation. J2EE speaks about flat (atomic) transactions, can JTS support multiple transactions? JTA vs JTS Author: Guy Pardon (http://www.jguru.com/guru/viewbio.jsp?EID=1208077), Oct 29, 2004 JTA is the Java transaction API, JTS is the mapping of CORBA's OTS to Java. JTS is a possible implementation of JTA, but there are other possibillities such as this embeddable java transaction service from the transaction management company. Guy Is JTS related to CORBA's Object Transaction Service (OTS)? Location: http://www.jguru.com/faq/view.jsp?EID=2564 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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 transaction manager can propagate transaction contexts to another JTS transaction manager via IIOP. How does a client application create a transaction object? Location: http://www.jguru.com/faq/view.jsp?EID=2566

Created: Dec 14, 1999 Modified: 2000-08-03 22:25:31.928 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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 name implies, the EJB container makes the decisions (based on the deployment descriptor's trans-attribute setting) regarding how to bundle operations into transactions and then works with the transaction manager, which manages the transaction processing. Bean-managed transactions. In this case, a session bean obtains the UserTransaction object via the EJBContext using the getUserTransaction() method.

JMS clients can bundle several messages in a transaction simply by using a transactional session--a UserTransaction object is not required. To create a transactional session, use either QueueConnection.createQueueSession() or TopicConnection.createTopicSession() with true as the first argument. (Some JMS implementations support JTA, so that it's also possible to obtain a UserTransaction object from the JMS server.) In other environments, for example, a web server that supports servlets and/or JavaServer Pages (JSP), a JMS server, and others, you obtain a UserTransaction object via JNDI. Of course, for a servlet to obtain a UserTransaction object, there must be a JTS-capable server to deliver the object. Typically, the server provides the JNDI look-up name either directly or via a system or server property. For example, with the WebLogic server, you would use a code segment similar to the following: ... Context c = new InitialContext(); UserTransaction ut = (UserTransaction) c.lookup("javax.jts.UserTransaction"); ut.begin(); // perform multiple operations... ut.commit() ... With J2EE implementations, you obtain the UserTransaction object with a code segment similar to the following: ... Context c = new InitialContext(); UserTransaction ut = (UserTransaction) c.lookup("java:comp/UserTransaction"); ut.begin(); // perform multiple operations... ut.commit() ...

If the environment provides the UserTransaction object via a system property, you would use a code segment similar to the following: ... String transName = System.getProperty("jta.UserTransaction"); Context c = new InitialContext(); UserTransaction ut = (UserTransaction) c.lookup(transName); ut.begin(); // perform multiple operations... ut.commit() ... JNDI remote look-up names and property names vary, of course, across servers/environment. Comments and alternative answers

WebLogic does it differently Author: Alex Chaffee (http://www.jguru.com/guru/viewbio.jsp?EID=3), Feb 14, 2003 In WebLogic 6.1, the JNDI name of the UserTransaction is either javax.transaction.UserTransaction or weblogic.transaction.UserTransaction I have found that the standard (?) JNDI name "java:comp.UserTransaction" or "java:comp/UserTransaction" does not always work. WebSphere 5.0 Author: Christoph Ernst (http://www.jguru.com/guru/viewbio.jsp?EID=1106402), Aug 6, 2003 In WebSphere 5.0 the JNDI-Lookup works like UserTransaction ut = (UserTransaction) ctx.lookup("jta/usertransaction");

See e.g. http://www3.ibm.com/software/webservers/appserv/doc/v30/ae/web/doc/ent_beans/atswpgec.htm Re: WebSphere 5.0 Author: Ralf Taugerbeck (http://www.jguru.com/guru/viewbio.jsp?EID=1119711), Oct 6, 2003

The link above is a bit outdated (from WAS 3.0 documentation). Check the current Infocenter for deta support in WAS 5.0:

http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.base.doc/info/

The lookup "jta/usertransaction" is still supported for J2EE apps with a spec level of 1.2 or lower. But 1.3 or later "java:comp/UserTransaction" is demanded.

Re[2]: WebSphere 5.0 Author: William Koscho (http://www.jguru.com/guru/viewbio.jsp?EID=1148721), Feb 24, 2004 I am familiar with looking up the JNDI reference, but I am having trouble defining the UserTransaction in Websphere. Can someone help me to set it up? How do I create a javax.transaction.UserTransaction object and map it to "java:comp/UserTransaction"? I am using WSAD 5.1 - any help is appreciated. Thanks, Bill Re[3]: WebSphere 5.0 Author: Donato Marrazzo (http://www.jguru.com/guru/viewbio.jsp?EID=1179813), Jun 18, 2004 You don't need set up nothing. java:comp/UserTransaction is implicitly defined, just use it! From J2EE 1.3 specs: "The J2EE platform must provide an object implementing the javax.transaction.UserTransaction interface to all web components. The platform must publish the UserTransaction object in the Java™ Naming and Directory Interface (JNDI) name space available to web components under the name java:comp/UserTransaction."

Re[4]: WebSphere 5.0 Author: himanshu Sharma (http://www.jguru.com/guru/viewbio.jsp?EID=1241678), Apr 29, 2005 We have a set of interface programs that use Open Adaptor framework for interfacing with external apps using MQ Series, JMS & Databases . The interface programs run in seperate JVMs and most of the time access at least two resources such as MQ and Database tables. Therefore it is neccesary to provide a two phase commit to preserve transacttion integrity across interface boundaries. In order to meet this requirement we need to understand how we can use WAS 5.1.1 (JTS impl) for XA compliant Datasources and JMS queues. I also feel that accessing WAS (Transaction Manager or UserTransaction object advertised over JNDI) is prohibited for client applications (seperate JVMs) other than the web apps. using java:comp/UserTransaction Author: Radhakrishnan Nariangadu (http://www.jguru.com/guru/viewbio.jsp?EID=752623), Aug 4, 2005 Can I use the J2EE JNDI lookup even within a EJB container?

I'm developing a Hibernate based DB component that will provide a uniform transactional interface anywhere,ie, J2EE container or normal JVM. Therefore within a Bean managed Session bean, rather than obtaining UserTransaction from the EJBContext will everything work smoothly if I obtain the UserTransaction using the JNDI lookup? I'm planning to switch to a non-managed configuration based on whether I can create an InitialContext. This will allow the same code to be unit tested in eclipse without having to run it within a App server. ...thanks in advance

How does a Java applet obtain a transaction object? Location: http://www.jguru.com/faq/view.jsp?EID=2568 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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 enduser client applications. The main objective of enterprise computing is to factor distributed applications so that server-intensive operations are handled by serverside application components. Do JTS implementations support nested transactions? Location: http://www.jguru.com/faq/view.jsp?EID=2569 Created: Dec 14, 1999 Modified: 2000-08-03 22:05:39.612 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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 latter operation will throw a NotSupportedException if the JTS implementation does not support nested transactions. Keep in mind that even if the JTS implementation supports nested transactions, this transaction manager-level support does not guarantee support for nested transactions in an application. For example, the EJB 1.1 specification does not support nested transactions. What are the ramifications of mixing JTA and non-JTA transactions where the same resources are involved? Location: http://www.jguru.com/faq/view.jsp?EID=2570 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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 such as database connections. In any situation where the possibility arises for both, design the application to use JTA transactions so that all transactions fall under the control of the transaction manager. If mixed transactions are necessary (for whatever reason), the application should manipulate the transactions in serial order, that is, start and finish the JTA transaction before creating the non-JTA transaction (or vice versa). If, for example, a JMS client creates a transaction via a UserTransaction and this transaction uses a database resource via the transaction manager, there could be problems if the same application directly accesses the database using a shared database connection. One of the advantages of using a J2EE-compliant environment is the resource coordination provided by the J2EE implementation via its JTS implementation. If, say, a servlet, accesses multiple resources, for example, via multiple enterprise beans, the J2EE implementation is responsible for ensuring that all related resource usage participates in the global, distributed transaction. Can different threads manipulate the same transaction? Location: http://www.jguru.com/faq/view.jsp?EID=2571 Created: Dec 14, 1999 Modified: 1999-12-14 14:08:03.575 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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, JMS, or whatever) server's transaction support as well as the transaction manager implementation. Comments and alternative answers

You likely can. Author: Tom Barnes (http://www.jguru.com/guru/viewbio.jsp?EID=569489), Dec 2, 2001 In general, this is possible, but the application must call suspend() on the first thread and then call resume() on the second thread to move the transaction there. These calls are found on javax.transaction.TransactionManager. The ability for the second thread to call commit() is in question though, some transaction managers may require that the transaction be moved back to the original thread before it can be called. JTA, J2EE 1.3 specification Author: Sean Sullivan (http://www.jguru.com/guru/viewbio.jsp?EID=203382), Jun 15, 2003 Sun's J2EE 1.3 specification discusses this topic. J2EE.4.2.3 Transactions and Threads

There are many subtle and complex interactions between the use of transactional resources and threads. To ensure correct operation, web components should obey the following guidelines, and the web container must support at least these usages.

• JTA transactions should be started and completed in the thread in which the service method is called. Additional threads that are created for any purpose, should not attempt to start JTA transactions. • Transactional resources may be acquired and released by a thread other than the service method thread, but should not be shared between threads. • Transactional resource objects (for example, JDBC Connection objects) should not be stored in static fields. Such objects can only be associated with one transaction at a time. Storing them in static fields would make it easy to erroneously share them between threads in different transactions. • Web components implementing SingleThreadModel may store transactional resource objects in class instance fields. The web container ensures that requests to a SingleThreadModel servlet are serialized and thus only one thread and one transaction will be able to use the object at a time. • In web components not implementing SingleThreadModel, transactional resource objects should not be stored in class instance fields, and should be acquired and released within the same invocation of the service method. • Enterprise beans may be invoked from any thread used by a web component. Transaction context propagation requirements are described above and in the EJB specification.

Can a servlet maintain a JTA UserTransaction object across multiple servlet invocations? Location: http://www.jguru.com/faq/view.jsp?EID=2572 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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. How does a client application that employs, say, session beans, obtain a JTA UserTransaction object from the EJB server? Location: http://www.jguru.com/faq/view.jsp?EID=2573

Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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 JTA transactions, for whatever reason, doing so is independent of the fact that it also uses enterprise beans (which implement their own transaction management via the EJB server); hence, the client must obtain the UserTransaction object in some other context, for example, from the J2EE environment. Why would a client application use JTA transactions? Location: http://www.jguru.com/faq/view.jsp?EID=2576 Created: Dec 14, 1999 Modified: 2000-08-03 22:03:56.209 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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 UserTransaction object. 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. Comments and alternative answers

Why would a client application use JTA transactions? Author: Mayank Jain (http://www.jguru.com/guru/viewbio.jsp?EID=791863), Mar 12, 2002 Do you think this would be a good approach? The client can have a Facade Session Bean in which the server could handle all the Transactions. How does a session bean obtain a JTA UserTransaction object? Location: http://www.jguru.com/faq/view.jsp?EID=2577 Created: Dec 14, 1999 Modified: 2000-08-03 22:19:19.481 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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 getUserTransaction() method. (It may also use JNDI directly, but it's simpler to use this convenience method.) Comments and alternative answers

Do you mean "use JNDI" or "use JTA&... Author: Alex Chaffee (http://www.jguru.com/guru/viewbio.jsp?EID=3), Aug 3, 2000 Do you mean "use JNDI" or "use JTA"? How would you do it with JNDI? Why would a session bean use bean-managed transactions? Location: http://www.jguru.com/faq/view.jsp?EID=2578 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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 unit of work. Comments and alternative answers

Good explanation Author: Santosh Malpekar (http://www.jguru.com/guru/viewbio.jsp?EID=30121), Mar 30, 2000 Good explanation Comments Author: Suresh S (http://www.jguru.com/guru/viewbio.jsp?EID=320716), Apr 10, 2001 If some scenarios would have given, it would be better to understand. Thanks How does an enterprise bean that uses container-managed transactions obtain a JTA UserTransaction object? Location: http://www.jguru.com/faq/view.jsp?EID=2579 Created: Dec 14, 1999 Modified: 2000-08-03 21:49:20.023 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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 transaction handling via the transaction attribute. Is it possible for a stateless session bean to employ a JTA UserTransaction object? Location: http://www.jguru.com/faq/view.jsp?EID=2580 Created: Dec 14, 1999 Modified: 2000-08-03 22:06:23.29 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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 invocations.) Thus, a stateless session bean can obtain a UserTransaction object via the EJBContext using the getUserTransaction() method, but it must start and finish each transaction within the scope of a method invocation.

How do you configure a session bean for bean-managed transactions? Location: http://www.jguru.com/faq/view.jsp?EID=2581 Created: Dec 14, 1999 Modified: 2000-08-24 18:54:58.201 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) You must set transaction-type in the deployment descriptor. Comments and alternative answers

What do you set transaction-type to? Author: Vikas Gholba (http://www.jguru.com/guru/viewbio.jsp?EID=126575), Aug 14, 2000 What do you set transaction-type to? Re: What do you set transaction-type to? Author: Sukanya Subramanian (http://www.jguru.com/guru/viewbio.jsp?EID=382541), Mar 21, 2001 Bean Bean Managed Author: Rajeev Sharma (http://www.jguru.com/guru/viewbio.jsp?EID=334960), Feb 23, 2001 Bean Managed How do you configure the transaction characteristics for a session bean with container-managed transactions? Location: http://www.jguru.com/faq/view.jsp?EID=2582 Created: Dec 14, 1999 Modified: 2000-08-24 18:55:27.106 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) You must set trans-attribute in the deployment descriptor. Comments and alternative answers

Set it to what? Can we have some sample code for the... Author: Alex Chaffee (http://www.jguru.com/guru/viewbio.jsp?EID=3), Aug 3, 2000 Set it to what? Can we have some sample code for the DD? Re: Set it to what? Can we have some sample code for the... Author: Damodara Rao (http://www.jguru.com/guru/viewbio.jsp?EID=428922), May 26, 2001 Within one transaction one row has to be inserted in oracle database throuh CMP EntityBean and the visibility of that row has to be made for inserting some other row in some other table because of constraints.How to make it visible within the transaction? Re[2]: Set it to what? Can we have some sample code for the...

Author: selva raju (http://www.jguru.com/guru/viewbio.jsp?EID=594229), Dec 23, 2001 I am not how you have the Entity Bean Design for that.But I think the following will be the Solution for you. Create one Method in Session Bean with the transaction Attribute as "Required" and call the Both the Entity Beans from that method.Here I have assumed that you two different entity beans to represent the two different tables.And specity the transaction attribute for the create method of the Entity Beans as "Supports" or "Required". How does an entity bean obtain a JTA UserTransaction object? Location: http://www.jguru.com/faq/view.jsp?EID=2583 Created: Dec 14, 1999 Modified: 2000-08-03 21:59:28.181 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) It doesn't. Entity beans do not employ JTA transactions; that is, entity beans always employ declarative, container-managed transaction demarcation. Entity beans, by definition, are somewhat tightly coupled (via the EJB container and server) to a datastore; hence, the EJB container is in the best position to manage transaction processing. Comments and alternative answers

The entity bean is not tightly coupled to the unde... Author: gaurav sharma (http://www.jguru.com/guru/viewbio.jsp?EID=210078), Sep 19, 2000 The entity bean is not tightly coupled to the underlying persistence framework. In fact the components are loosely coupled and are tightly cohesive with the interface. The container transaction API's enable the binding of components to the data interface layer transparently to the implementation of the component. Is it necessary for an entity bean to protect itself against concurrent access from multiple transactions? Location: http://www.jguru.com/faq/view.jsp?EID=2584 Created: Dec 14, 1999 Modified: 2000-08-03 22:26:36.274 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) No. One of the motivations for using a distributed component architecture such as Enterprise JavaBeans is to free the business logic programmer from the burdens that arise in multiprogramming scenarios. Comments and alternative answers

The answer to this question is really misleading in... Author: dan benanav (http://www.jguru.com/guru/viewbio.jsp?EID=8173), Jan 25, 2000 The answer to this question is really misleading in my opinion.

It is true that calls to the bean instance's methods are serialized, however calls to the entity object are not. That means from the client's perspective calls to the methods can occur concurrently. The bean provider also has to be aware of and code for that. For example, suppose you have a bean that has a qty field and a method called updateQuantity. Then you could define updateQuantity in the bean class as public void updateQty(int q){ qty -=q; } However this could lead to incorrect behavior because the container is free to create several instances of the bean to process method requests. Calls to these methods (on two different beans) can occur concurrently and that is the problem. So for example each instance gets the qty from the database and could start out with the same qty. When the qty is decreased in each of two calls in two transactions each bean would decrease it's qty and store it back to the database. Here is a better picture, Transaction 1 calls updateQty. Container uses bean1 to process request. Transaction 2 calls updateQty on the same entity object. Container uses bean2 to process request. Container calls ejbLoad on bean1 which gets qty from a database. Value is 1. Container calls ejbLoad on bean2 which gets qty from a database. Value is 1. Container calls bean1 updateQty. qty field in bean1 becomes 0. Container calls bean2 updateQty. qty field in bean2 becomes 0. Container calls ejbStore on bean1 which stores 0 into the database. Container calls ejbStore on bean2 which stores 0 into the database. This of course is the wrong answer. I should store -1 into the db. There is a common misconception that since the container serializes calls to the bean instance that calls to the bean object are serialized. Hence the programmer must either serialize calls to the object or must use features of the database to handle the above situation. Serializing calls to the entity and session objects does not happen automatically. For session objects the container will throw an exception if the calls happen concurrently. Even many companies that develop ejb servers hold these misconceptions. Re: The answer to this question is really misleading in... Author: Mayank Jain (http://www.jguru.com/guru/viewbio.jsp?EID=791863), Mar

12, 2002 hi dan, If your answer is with respect to EJB 1.0 or EJB 1.1 specifications then you may be right... But as far as I know according to EJB 2.0 specifications... the client may or may not serialize his calls to an entity bean.... it is the container's responsibility to serialize the transactions (in case of Commit option A) or allow shared access to instances(in case of Commit Option B or Commit Option C). With respect to the comment given by dan henany -- The... Author: Vallur Narasimhan (http://www.jguru.com/guru/viewbio.jsp?EID=50672), May 17, 2000 With respect to the comment given by dan henany -The instance methods of the beans are serialized with respect to transactions but not individually with respect to methods. So just declarative knowledge is enough. Is an EJB, JMS, or general-purpose Java application server a transaction manager? Location: http://www.jguru.com/faq/view.jsp?EID=2586 Created: Dec 14, 1999 Modified: 2000-08-03 22:04:29.484 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) It depends on the server implementation. The JTA and JTS specifications define client-, application-, and transaction manager-level operations. There is nothing to prevent a Java application server from implementing, JMS, EJB, and JTS functionality. On the other hand, it could (if available) obtain transaction manager services indirectly from another server. Is it possible for server-side applications, for example, a JMS application, to play the role of a resource in a distributed transaction? Location: http://www.jguru.com/faq/view.jsp?EID=2587 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) Under certain conditions, yes. In this particular case, the JMS server would have to implement the appropriate resource-related interfaces in javax.transaction.xa so that the JTS transaction manager can enlist the JMS server as an intermediary, playing the role of a resource manager with respect to the JMS application. How does a client use the javax.transaction package? Location: http://www.jguru.com/faq/view.jsp?EID=2588 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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 as NotSupportedException, 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. How does a client use the javax.jts package? Location: http://www.jguru.com/faq/view.jsp?EID=2589 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) Clients do not use this package. This package prescribes functionality that is implemented by JTS transaction managers. How does a client use the javax.transaction.xa package? Location: http://www.jguru.com/faq/view.jsp?EID=2590 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) 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. How does a JTS transaction manager perform an xa_open operation? Location: http://www.jguru.com/faq/view.jsp?EID=2591 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) In the distributed Java world, resource manager initialization is handled automatically upon resource connection.

Note that the XAResource interface differs from the standard X/Open XA interface; see the JTA specification and the API documentation. Can a JMS client obtain a JTA UserTransaction object? Location: http://www.jguru.com/faq/view.jsp?EID=2594 Created: Dec 14, 1999 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) The JMS specification does not require that JMS implementations support distributed transactions. If a JMS implementation supports distributed transactions, it's likely that it will do so through the JTA API, providing a JTA UserTransaction object via JNDI. What is two-phase commit? Location: http://www.jguru.com/faq/view.jsp?EID=20929 Created: Mar 6, 2000 Modified: 2000-03-07 07:44:43.19 Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9) Question originally posed by rajesh kkkkkkkkk (http://www.jguru.com/guru/viewbio.jsp?EID=16780 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 Otherwise:  Coordinator instructs participating resource managers to "ROLLBACK"  Participants complete their respective local undos 

o

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. What newsgroups and mailing lists are available for discussing transactions? Location: http://www.jguru.com/faq/view.jsp?EID=23915 Created: Mar 13, 2000 Modified: 2000-03-14 07:16:16.66 Author: John Zukowski (http://www.jguru.com/guru/viewbio.jsp?EID=7) Question originally posed by John Mitchell PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=4 The advanced-java mailing list is probably your best bet for finding help for discussing transactions. As far as newsgroups go, I would guess that comp.lang.java.corba is your best bet. You can probably have fun by posting to the microsoft.public.microsoft.transaction.server.programming newsgroup. Are there any good books about transactions (especially w.r.t. to Java)? Location: http://www.jguru.com/faq/view.jsp?EID=23916 Created: Mar 13, 2000 Modified: 2000-03-14 07:19:19.789 Author: John Zukowski (http://www.jguru.com/guru/viewbio.jsp?EID=7) Question originally posed by John Mitchell PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=4 The Programming with Enterprise JavaBeans, JTS, and OTS book from Andreas Vogel and Madhavan Rangarao is rumored to be good, though it is approaching a year old. The Java Enterprise in a Nutshell book provides API-level coverage, but if you don't know it already, it won't help. Comments and alternative answers

The two books that give the complete picture of tr... Author: Richard Williams (http://www.jguru.com/guru/viewbio.jsp?EID=2390), Mar 14, 2000 The two books that give the complete picture of transactions are: Principles of Transaction Processing (Morgan Kaufman Series in Data Management Systems) ISBN: 1558604154 by Philip A. Bernstein, Eric Newcomer (Contributor), Phillip Bernstein and Transaction Processing : Concepts and Techniques (Morgan Kaufmann Series in Data Management Systems) ISBN: 1558601902 by Jim Gray, Andreas Reuter The first book is more of an overview, but covers the subject sufficiently well, while the second is considered the definitive book on transactions. Not very Java flavored, but these books are universally applicable to the subject and not confined to

one platform. Study these and you will have no problem understanding the Java APIs. Transactions article Author: Jerry Smith (http://www.jguru.com/guru/viewbio.jsp?EID=9), Apr 30, 2001 Although it's not a book, J2EE Transaction Frameworks is a good tutorial-type article. My session beans call other bean methods within a transaction. Using beanmanaged transactions, how should I take care of commit and rollback ? Location: http://www.jguru.com/faq/view.jsp?EID=62121 Created: Jun 2, 2000 Modified: 2000-09-12 15:55:36.874 Author: Siva Visveswaran (http://www.jguru.com/guru/viewbio.jsp?EID=46210) Question originally posed by Shalabh Nigam (http://www.jguru.com/guru/viewbio.jsp?EID=47481 There are two steps here: 1. Coding step: public class exBean implements SessionBean { EJBContext ec; javax.transaction.UserTransaction utxn; . . . utxn = ec.getUserTransaction(); utxn.begin();

}

// do all your txn stuff // getting DB connections, updates, other bean methods, etc. . . utxn.commit();

Note you have to begin a txn before opening dB connections and close connections before committing. 2. Deployment step: - Your app server must support a JTS for distributed txns. Most do. - Verify there is no conflict with the bean transaction properties in calling beans. Comments and alternative answers

Are there any issues if each of my bean methods uses... Author: Shalabh Nigam (http://www.jguru.com/guru/viewbio.jsp?EID=47481), Jul 3, 2000 Are there any issues if each of my bean methods uses a different DB Connection?

How are JMS, JTS, JTA, RMI, EJB, and CORBA related? Location: http://www.jguru.com/faq/view.jsp?EID=94749 Created: Jul 4, 2000 Modified: 2000-07-04 04:24:01.597 Author: John Zukowski (http://www.jguru.com/guru/viewbio.jsp?EID=7) Question originally posed by John Mitchell PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=4 They are all components of the Java 2 Enterprise Edition. See http://java.sun.com/j2ee/ for information on the J2EE technologies. Is it possible to write a stand-alone application (a client or a non-J2EE environment) that can take advantage of distributed transactions using JTA? How? Is it vendor dependent, or are there any standards for writing such applications? Location: http://www.jguru.com/faq/view.jsp?EID=120645 Created: Aug 6, 2000 Modified: 2000-08-07 08:21:48.473 Author: Robert Castaneda (http://www.jguru.com/guru/viewbio.jsp?EID=4362) Question originally posed by Tharak Krish (http://www.jguru.com/guru/viewbio.jsp?EID=10101 You can use an implementation of JTA that uses JTS. JTS is the Java Mapping of the CORBA OTS (Object Transaction Service) that supports distributed transactions. The JTA/JTS service would have to support distributed transactions. ORB/J2EE vendors usually provide this support--the Inprise Application Server provides this functionality. How does a bean access multiple databases in the same transaction? Location: http://www.jguru.com/faq/view.jsp?EID=120647 Created: Aug 6, 2000 Modified: 2000-08-07 08:28:02.592 Author: Robert Castaneda (http://www.jguru.com/guru/viewbio.jsp?EID=4362) Question originally posed by srinivas rallapalli (http://www.jguru.com/guru/viewbio.jsp?EID=14867 In EJB 1.1, the way your EJB accesses multiple databases is the same as for accessing a single database: the datasource is defined in the deployment descriptor and looked up by the EJB using the JNDI environment naming context, that is, java:comp/env. It is the responsibility of the container/server to handle the transaction context propagation and the synchronization/2PC behavior. Warning: this functionality, accessing multiple databases in EJB within the same transaction context, is not supported by all products. Comments and alternative answers

In your warning you mention that all products do s... Author: Rahul Khimasia (http://www.jguru.com/guru/viewbio.jsp?EID=55768), Feb

1, 2001 In your warning you mention that all products do support accessing multiple databases within the same transaction context. Can you please specify the features one should look for in application servers and databases products, so it is possible to span a transaction across multiple databases? Do Sun's J2EE reference implementation and the Cloudscape database fulfill this requirement? Re: In your warning you mention that all products do s... Author: Santosh Baboo (http://www.jguru.com/guru/viewbio.jsp?EID=829580), Apr 8, 2002 Look for support for Distributed Transaction or 2-phase commits. How can I manage long duration transactions? Location: http://www.jguru.com/faq/view.jsp?EID=121370 Created: Aug 7, 2000 Modified: 2000-08-08 10:47:03.732 Author: Siva Visveswaran (http://www.jguru.com/guru/viewbio.jsp?EID=46210) Question originally posed by John Mitchell PREMIUM (http://www.jguru.com/guru/viewbio.jsp?EID=4 By saying "how do I manage" it seems like you are doing bean-managed transaction using the javax.transaction.UserTransaction interface 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. Comments and alternative answers

I think the author is not addressing the issue of ... Author: Subrahmanyam Allamaraju (http://www.jguru.com/guru/viewbio.jsp?EID=265492), Dec 15, 2000 I think the author is not addressing the issue of "long" transactions. Instead, this answer talks about bean-managed transactions across multiple method invocations of a bean--this is easy to achieve by bracketing the method with a user transaction. However, long transactions occur when one tries to implement business use cases requiring human (or even other system) interaction. As long as the transaction context can be maintained across multiple invocations, it is possible to maintain a "long"

transaction across the complete business use case. Coming back to the question, the basic requirement is the ability to maintain the transaction context across the use case. For instance, consider a web-based implementation of a use case--the implementation consisting of several HTTP requests with each request resulting in certain transactional resource access. In this case, the transaction context is associated with the thread of execution of the request. That is, the lifetime of the transaction context cannot be beyond the scope of the request. In this model, it is not possible to implement long transactions as the transaction context cannot be propagated across multiple requests. As far as the J2EE server is concerned, each request involves a new transaction. A possible alternative is to use Java application clients. In this case, as long as the application client is alive, it is possible to maintain the user transaction object, and therefore the transaction context is maintained across all the requests from the application client to the beans. Considering performance, it is worth considering to break such long transactions in to short transactions, and maintain the state of the business use case programmatically.

Re: I think the author is not addressing the issue of ... Author: A Varma (http://www.jguru.com/guru/viewbio.jsp?EID=501445), Sep 21, 2001 I agree with the answer above. I think the notion of attaining the same result as a 'long' transaction - based on not committing a transaction at the end of a method call, is flawed. Here's why: 1. It is true that a session bean can maintain data between multiple http requests. 2. Say you have transaction A part of request A and transaction B part of request B - both requests A and B being part of the same session - and request A preceding request B. 3. One would assume that if transaction A was not committed - and then at the end of transaction B - both A and B were committed - one would attain the 'long' transaction effect. However, at the end of request A, one has lost the transaction A context - and hence transaction A cannot be committed at the end of transaction B - even though the two belong to the 'same session'. The only way to attain something like the above would be through nested transactions - and the J2EE platform only supports flat transactions. A flat transaction cannot have any child (nested) transactions. Re[2]: I think the author is not addressing the issue of ...

Author: Samir Zeort (http://www.jguru.com/guru/viewbio.jsp?EID=1206589), Oct 21, 2004 If you want to span one transaction in several http requests this is possible if you have stateful session bean A with bean -managed transaction demarcation , you start transaction in first http request by UserTransaction.begin() and at the end of bussines method (end of request) the container would keep your transactional state (i.e. the transaction ) and it would be resumed by the next call . This is at least what I call "long running" transaction. The problems around long transactions are connection handling- connections stays open between user iteraction which is a problem because its expensive resource . What happens for example if client "forget" to do next http call ? That's why maybe its helpful if one uses XA transactions which do not require to keep connection associated with given transaction. Instead , a transaction identifier is used (Xid) . But this would not save the problem with running user session in the database . Where can I find the API documentation for the Java Transaction API (JTA)? Location: http://www.jguru.com/faq/view.jsp?EID=134146 Created: Aug 24, 2000 Modified: 2000-08-24 11:16:10.042 Author: John Mitchell (http://www.jguru.com/guru/viewbio.jsp?EID=4) You can find the JTA documentation from Sun's J2EE API documentation page. I am initiating a JTA transaction within a servlet. Subsequently, this servlet calls the method of a stateful session EJB. In this method some SQL statements are executed and an entity bean is looked up and updated. After the return of that method, the servlet commits the JTA transaction. The stateful session EJB as well as the entity EJB are declared as with TRANSACTION REQUIRED and are placed in two different EJB servers. However, after commit, only the changes due to the SQL statements are done in the database. It looks like the entity bean EJB server does not consider the JTA transaction. Any idea? Location: http://www.jguru.com/faq/view.jsp?EID=206928 Created: Sep 15, 2000 Modified: 2000-09-15 07:06:58.469 Author: Gene De Lisa (http://www.jguru.com/guru/viewbio.jsp?EID=38746) Question originally posed by gilles weber (http://www.jguru.com/guru/viewbio.jsp?EID=202352 You say that your business requirements are to start a transaction at the beginning of the session bean method and then to terminate it at the end of the session bean method. Why don't you forget about starting the transaction in the servlet and let CMT in the beans do their thing? Think of the session bean methods as "use-case" methods. If they use entity beans, you'll usually set the methods to REQUIRES_NEW and the entity bean methods to one that lets it be in the session bean context (mandatory, required, supports). Why is the session bean updating the database? Are you implementing SessionSynchronization too? Usually, for the sake of transaction handling if you're

updating you'll use entities. If the session bean is just reading, then using database data is okay (but you'll probably want to also implement SessionSynchronization). Comments and alternative answers

2 Phase Commit Author: prajakt samant (http://www.jguru.com/guru/viewbio.jsp?EID=272793), Mar 22, 2001 All the EJB Containers do not support distributed transcation(2PC).As in your case the session beans and entity beans reside on different servers,the case might be that container might not support Distributed Transcation,Hence changes might not be updated. Re: 2 Phase Commit Author: Karthik Karthik (http://www.jguru.com/guru/viewbio.jsp?EID=412623), May 5, 2001 If the second EJB server (or container) that received the distributed transactional context can not be a part of the 2 phase coommit protocol it would throw an exception stating that it can not accept transactional contexts emerging from other servers. Even if it fails to do it, since the TX attribute is defined as TX_REQUIRED, the second container would have supplied this bean with a new transaction which would have commited the entity EJB data when the method completed. Normally the term 2 phase commit is used to mean you are accessing 2 different databases within the same transaction (regardless of whether the transaction context is propgated to another EJB server). In this case, it seems both containers write to the same database. Strictly speaking, this is a distributed transaction, rather than 2 phase. Thanks, Karthik. Where can I learn (more) about Java's support asynchronous and publish/subscribe messaging using JMS (Java Message Service)? Location: http://www.jguru.com/faq/view.jsp?EID=431210 Created: May 30, 2001 Author: John Mitchell (http://www.jguru.com/guru/viewbio.jsp?EID=4) Check out the jGuru JMS FAQ. Where can I learn (more) about Java's support for developing multithreaded programs? Location: http://www.jguru.com/faq/view.jsp?EID=431248 Created: May 30, 2001 Author: John Mitchell (http://www.jguru.com/guru/viewbio.jsp?EID=4) Check out the jGuru Threads FAQ. Where can I learn (more) about JCA (Java Connector Architecture)? Location: http://www.jguru.com/faq/view.jsp?EID=431958 Created: May 31, 2001 Author: John Mitchell (http://www.jguru.com/guru/viewbio.jsp?EID=4)

Check out the Sun's Java Connector Architecture homepage. What is the default time for transaction manager? And how to set maximum time(timeout) for transaction?. Location: http://www.jguru.com/faq/view.jsp?EID=1050395 Created: Jan 26, 2003 Author: Nick Maiorano (http://www.jguru.com/guru/viewbio.jsp?EID=780589) Question originally posed by venkata devi prasad kankanalapalli (http://www.jguru.com/guru/viewbio.jsp?EID=1034636 The default time depends on your app server. It is usually around 30 seconds. If you are using bean-managed transactions, you can set it like this: // One of the methods from the SessionBean interface public void setSessionContext(SessionContext context) throws EJBException { sessionContext = context; } // Then, when starting a new transaction UserTransaction userTransaction = sessionContext.getUserTransaction(); userTransaction.setTransactionTimeout(60); userTransaction.begin(); // do stuff userTransaction.commit(); If you are using container-managed transactions, this value is set in a app server specific way. Check your app server's deployment descriptor DTD.