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?

Created: Dec 14, 1999
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?

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?

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)?

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)?

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 kirupa_raj@rediff.com 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)?

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?

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:
...
c.lookup("java:comp/UserTransaction");
ut.begin();
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");
UserTransaction ut = (UserTransaction) c.lookup(transName);
ut.begin();
ut.commit()
...
JNDI remote look-up names and property names vary, of course, across
servers/environment.
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
ctx.lookup("jta/usertransaction");
See e.g. http://www-
3.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

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."

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?

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. The main objective of enterprise computing is to factor
distributed applications so that server-intensive operations are handled by server-
side application components.
Do JTS implementations support nested transactions?

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?
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?

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.
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?
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?
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?

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.
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?

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.)

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?

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.
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?
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?
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?
You must set transaction-type in the deployment descriptor.
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?
You must set trans-attribute in the deployment descriptor.
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?

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.
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?
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.
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?
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?
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?

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?

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?

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?

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?

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?

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
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.
What newsgroups and mailing lists are available for discussing

transactions?
Author: John Zukowski (http://www.jguru.com/guru/viewbio.jsp?EID=7) Question
originally posed by John Mitchell PREMIUM
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)?
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.
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 bean-
managed transactions, how should I take care of commit and rollback ?
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
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.
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?
Created: Jul 4, 2000 Modified: 2000-07-04 04:24:01.597
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?
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
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?

Author: Robert Castaneda (http://www.jguru.com/guru/viewbio.jsp?EID=4362)
Question originally posed by srinivas rallapalli
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.
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?

Author: Siva Visveswaran (http://www.jguru.com/guru/viewbio.jsp?EID=46210)
Question originally posed by John Mitchell PREMIUM
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.
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)?
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?
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
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).
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)?
Created: May 30, 2001
Check out the jGuru JMS FAQ.
Where can I learn (more) about Java's support for developing multi-
threaded programs?
Check out the jGuru Threads FAQ.
Where can I learn (more) about JCA (Java Connector Architecture)?

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?.
Created: Jan 26, 2003
Author: Nick Maiorano (http://www.jguru.com/guru/viewbio.jsp?EID=780589)
Question originally posed by venkata devi prasad kankanalapalli
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.

Transactions FAQ From Jguru

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Transactions FAQ From Jguru

Încărcat de

Drepturi de autor:

Formate disponibile

Transactions FAQ From jGuru

Generated Sep 13, 2005 2:24:18 PM

A transaction is an abstraction of an atomic and reliable execution sequence.

Transaction processing is important for almost all modern computing environments

During an atomic execution sequence a concurrency control algorithm manages

Concurrency control and recovery algorithms are based in part on serializability

What is a distributed transaction?

A distributed transaction bundles multiple operations in which at least two network

In order to satisfy a client's dependence on an all-or-nothing guarantee for a

What is the acronym ACID?

ACID represents the four properties of every transaction:

• Atomicity - Either all of the operations bundled in the transaction are

What parties are involved in transaction processing?

There are five principals:

• One or more client applications - optionally initiate client-based transactions

What is the Java Transaction API (JTA)?

JTA is a service-oriented API specification. Typically, we think of JTA as the service

• Transactional operations in client applications

The most noticeable and often-used functionality is

What is the Java Transaction Service (JTS)?

JTS is a specification for implementing a Java transaction manager. A transaction

Comments and alternative answers

What is the difference between JTA and JTS? When must...

Is JTS related to CORBA's Object Transaction Service (OTS)?

How does a client application create a transaction object?

• Container-managed transactions. As the name implies, the EJB container

JMS clients can bundle several messages in a transaction simply by using a

Comments and alternative answers

WebLogic does it differently

Re: WebSphere 5.0

Re[3]: WebSphere 5.0

You don't need set up nothing. java:comp/UserTransaction is implicitly

Re[4]: WebSphere 5.0

I also feel that accessing WAS (Transaction Manager or

I'm planning to switch to a non-managed configuration based on whether I can create

How does a Java applet obtain a transaction object?

It shouldn't, no matter how clever the programmer! Applets, by definition, should be

Do JTS implementations support nested transactions?

A JTS transaction manager must support flat transactions; support of nested

It depends on the context/resource. In general, you shouldn't create this type of

One of the advantages of using a J2EE-compliant environment is the resource

Can different threads manipulate the same transaction?

If thread t1 executes UserTransaction.begin() and thread t2 executes

Comments and alternative answers

You likely can.

JTA, J2EE 1.3 specification

• Transactional resources may be acquired and released by a thread

• Transactional resource objects (for example, JDBC Connection

• Web components implementing SingleThreadModel may store

• In web components not implementing SingleThreadModel, transactional

• Enterprise beans may be invoked from any thread used by a web

Can a servlet maintain a JTA UserTransaction object across multiple servlet

Why would a client application use JTA transactions?

Comments and alternative answers

Why would a client application use JTA transactions?

How does a session bean obtain a JTA UserTransaction object?

If it's necessary to engage in explicit transaction management, a session bean can be

Comments and alternative answers

Why would a session bean use bean-managed transactions?

Comments and alternative answers

How does an enterprise bean that uses container-managed transactions

It doesn't! By definition, container-managed transaction processing implies that the