Are local transactions and BMT same?
Do we need transactionManager for local transactions?
I read transactionManager will be ineffective for local transactions. is that correct?
JTA give provision for both CMT and BMT?
There is no difference in local or global transaction handling concerning BMT or CMT.
BMT and CMT only define how the start and end of transactions may be defined. In CMT it is defined by the calls of annotated methods, in BMT the start and end of transactions is defined using the UserTransaction-object.
If a global transaction is necessary or better a distributed transaction, then the Transactionmanager will arrange that, independent on BMT or CMT.
These global transactions or two phase commit become necessary as soon as more then one transaction resource is involved. For instance if you use a MessageDriven bean which calls a bean annotated as "Beanmanaged transaction handling" and doing changes in a DBMS. In that case the two-phase commit is done for both resources the message queue and the DBMS.
So, to answer your questions:
No, answer see above.
You can't do transactions with more than one resource without transactionmanager. A container providing distributed transactions as J2EE-Containers normally do, will handle all transactions using a Transactionmanager. At jboss you can configure datasources as "no jta" in that case you explicitly exempt them from two-phase commits, but I think the jboss-transactionmanager will handle the db-connections of such a datasource in spite of that.
Yes, if by "give provision" you mean "supports"
Below are few points for your question in order.
Global transaction support is available to Web and enterprise bean J2EE components and, with some limitations, to application client
components.
Enterprise bean components can be subdivided into two categories: beans that use container-managed transactions (CMT),
and those that use bean-managed transactions (BMT).
A local transaction containment (LTC) is used to define the
application server behavior in an unspecified transaction context.
An LTC is a bounded unit-of-work scope, within which zero, one, or
more resource manager local transactions (RMLT) can be accessed. The
LTC defines the boundary at which all RMLTs must be complete; any
incomplete RMLTs are resolved, according to policy, by the
container. An LTC is local to a bean instance; it is not shared
across beans, even if those beans are managed by the same container.
LTCs are started by the container before dispatching a method on a
J2EE component (such as an enterprise bean or servlet) whenever the
dispatch occurs in the absence of a global transaction context. LTCs
are completed by the container depending on the
application-configured LTC boundary, for example, at the end of the
method dispatch. There is no programmatic interface to the LTC
support; LTCs are managed exclusively by the container and
configured by the application deployer through transaction
attributes in the application deployment descriptor.
A local transaction containment cannot exist concurrently with a
global transaction. If application component dispatch occurs in the
absence of a global transaction, the container always establishes an
LTC for J2EE components at J2EE 1.3 or later.
If an application uses two or more resources, an external transaction manager is needed to coordinate the updates to all resource managers in a global transaction.
for more info. on Transaction Managers : https://access.redhat.com/documentation/en-US/Fuse_ESB_Enterprise/7.1/html/EIP_Transaction_Guide/files/TxnManagers-WhatIs.html
BMT enterprise beans, application client components, and Web components can use the Java Transaction API (JTA) UserTransaction
interface to define the demarcation of a global transaction. To
obtain the UserTransaction interface, use a Java Naming and
Directory Interface (JNDI) lookup of java:comp/UserTransaction, or
use the getUserTransaction method from the SessionContext object.
The UserTransaction interface is not available to CMT enterprise
beans.If CMT enterprise beans attempt to obtain this interface, an
exception is thrown, in accordance with the Enterprise JavaBeans
(EJB) specification.
A Web component or enterprise bean (CMT or BMT) can get the
ExtendedJTATransaction interface through a lookup of
java:comp/websphere/ExtendedJTATransaction. This interface
provides access to the transaction identity and a mechanism to
receive notification of transaction completion.
Related
I am trying to understand the transactions, and more specifically i am doing it using Spring framework. Going through the material that i have (both internet and books), i see these terminologies:
Container managed transactions (CMT).
Bean Managed transactions (BMT).
Java transaction API (JTA).
Also, for a large enterprise level application, terminologies like "local" and "global" transactions too i have encountered.
What i have understood, is that global transactions is for the cases in which we are managing two or more different resouces (like One Oracle DB, other MySQL etc) and commits/rollback to them happen if both are success/failure. Local transactions is for when we have only one resource to manage (like only one DB connection to MySQL).
I have following doubts:
While writing a simple JDBC standalone program, we can code to commit/rollback. I believe this is example of local transaction, is this correct? And is this transaction taken care by "JDBC" library itself or the drivers?
What is CMT? What i understand is that Container takes care of the transaction management (like Jboss AS). If this is correct, how internally does it manages? Are CMT local or global? Do they use JDBC API's internally to manage the transactions?
What is BMT? This i am not able to understand. We can have application deployed in an App server (and i believe in those cases the transaction would be managed by Container) or i can write an standalone application in which i can use the transaction management code myself (try .. catch block etc). So, which category BMT falls?
While reading Spring framework, i read that Spring framework have its own way of managing the transaction. Down the line, i read Spring Framework uses JTA to manage transactions? I am confused about this. If JTA is API, do we have multiple vendors who implement JTA (like for JPA, we can have multiple vendors who provide the implementation e.g. Hibernate).
Is JTA for local or global transactions? When i write a simple JDBC program to manage transaction, does it use API's which comply JTA? Or is JTA totally different from transaction management which simple JDBC program uses?
Same for CMT, does CMT follow the rules which JTA has in place (the API's primarily)?
It would be great if you answer point-wise, i did search on net, my doubts are still not answered.
Concerning local/global transaction: by global I suppose you are talking about XA transaction (2 phase commits : http://en.wikipedia.org/wiki/X/Open_XA). This is just mandatory when you deal with multiple databases or transactionnal resources.
yes it's a "local transaction", it means only one database is
part of the transaction. The transaction is managed by the database
and controlled by JDBC in that case.
CMT : Container Managed: the container will detect the start and
the end of the transaction and will perform commit/rollback
depending on method return status (successfull return : commit,
exception : rollback). CMT rely on JTA to manage transactions on its
resources. Then it's up to the proper resource adapters (RA) to talk
to jdbc or any other drivers related to your EIS (data). Look at
http://docs.oracle.com/javaee/5/tutorial/doc/bncjx.html
BMT: it means it's up to the bean to control transaction
boundaries. It's pretty rare to use this kind of transaction
management these days. With BMT you control the UserTransaction
object, it's an error to control transaction boundaries directly
with JDBC. Bear in mind also that even if you are in BMT some
framework like JPA (not JTA) will invalidate current transaction on
any error even if you did not explicitely requested a rollback. It
means it's quite hard/dangerous/useless to use BMT.
JTA (I hope you did not mispelled JPA) is at another level: JTA
the API a resource adapter must implement to be part of a container
transaction. Apart from UserTransaction class (what you'll use in
BMT to control transaction boundaries) you have nothing to do with
JTA. There is no multiple implementation of JTA but there is multiple implementation of JTS (Java Transaction Service), each application server vendor implements their own JTS.
JTA is a API for framework designer, JTA impose a contract to the
Resource Adapter RA, and the RA will use JDBC or any other API to
deal with it's EIS (Enterprise Information Storage, let's call it
your DB). JTA works for XA and non XA transactions (if your RA supports XA transactions).
CMT uses JTA, but again JTA is a lowlevel contract between
components of the application server. Application designer should
not care about JTA.
I am using spring3 and Hibernate4 with Tomcat7.
I have to use JTATransactionManager and i have below configuration.
<bean id="transactionManager"
class="org.springframework.transaction.jta.JtaTransactionManager">
<property name="userTransactionName" value="java:comp/UserTransaction"></property>
</bean>
In above configuration where is java:comp/UserTransaction defined?
Thanks!
It is a JNDI reference to container-supplied user transaction object.
It is not user configurable as such (as in you cannot change the value yourself). The value depends on the EE container you use.
As to what user transaction object really is, see Wikipedia:
UserTransaction interface
The javax.transaction.UserTransaction interface provides the
application the ability to control transaction boundaries
programmatically. This interface may be used by Java client programs
or EJB beans.
The UserTransaction.begin() method starts a global transaction and
associates the transaction with the calling thread. The
transaction-to-thread association is managed transparently by the
Transaction Manager.
Support for nested transactions is not required. The
UserTransaction.begin method throws the NotSupportedException when the
calling thread is already associated with a transaction and the
transaction manager implementation does not support nested
transactions.
Transaction context propagation between application programs is
provided by the underlying transaction manager implementations on the
client and server machines. The transaction context format used for
propagation is protocol dependent and must be negotiated between the
client and server hosts. For example, if the transaction manager is an
implementation of the JTS specification, it will use the transaction
context propagation format as specified in the CORBA OTS 1.1
specification. Transaction propagation is transparent to application
programs..
JTA and associated with it XA transactions are tricky things to implement and support. As #js-nizet said only JEE Application servers have their own transaction managers implementation working out of the box. For lightweight web server like Tomcat or Jetty you have to provide an external implementation and to configure the Spring to work with it. There are a lot of choices so it is up to you. I can recommend you Jboss' Narayana, but it is really up to you. Since it is not so straight-forward to have this running I would recommend you the following blog post which describes everything in a great detail - Configuring Spring and JTA without full Java EE.
Here's another post on how to configure Narayan with Spring and Jetty.
With respect to EJB 3.0 transaction propagation, I have the following basic question.
This is my scenario : EJB Service -> POJO -> EJB Dao. I need to stick to this architecture due to some constraints within the organization.
So, in EJB Service Tx starts, I direct to a POJO which returns the local EJB DAO. Now within the methods of the EJB DAO, I inject the persistence context and the Entity Manager and the methods have been annotated with TransactionAttribute (Required). So my question is if within the DAO EJB will the transaction context of the Service EJB be used or will it start a new transaction due to the POJO layer in between.
Any help would be appreciated.
Thanks..Vijay
Since a transaction is started from the "EJB Service", it will be propagated to the "EJB DAO". The transaction is set as a kind of thread local (at least conceptually, I don't know how implementations do it). That is unless the POJO does anything like running the DAO in a newlly created thread (which -for manually created threads- is inappropriate for Java EE anyway).
I have an application that has a struts 1.1 and EJB 2 combination, but now we are introducing a new piece into it with hibernate 3.2. The hibernate DAO's run in parallel with the EJB 2 session bean DAO's with pure JDBC. I am concerned about the jdbc connections management in this case. Since EJB 2.0 has container managed connections and transactions. But in the case of hibernate we begin and commit a hibernate transaction, Will it be safe to assume there will not be any issues with this architecture.
Need some analysis help.
PM
I was contemplating on the same issue, if hibernate module which might access existing tables being used by JDBC DAO's whose transaction is managed by Session Beans. But here is my approach:
I will have a delegate that invokes the EJB session bean, and since this bean will be responsible to manage transactions, I will create my hibernate DAO's and invoke them from this session bean, which I assume will not have any issues.
The hibernate session factory for this application will be instantiated once using the hibernate plugin that will be part of the struts config xml and will be saved as part of the servlet context and then the action class will pass this sessionfactory instance from the EJB session bean delegate to the hibernate DAO.
I guess this will be a clean approach, since the transaction will be managed by the EJB Session bean which are deployed onto the websphere. The JDBC connection pools management since is configured on the websphere and being accessed using the datasources, hibernate does not have to worry about this.
Please help me if I am on the right path with my assumptions ?
Transactions demarcate logical unit of work and hence are inherently isolated. But I am wondering why you need a combination of both. If you are already using EJB2 + JDBC why not stick to this?
Hibernate can be used without any problem with CMT (or BMT) session beans, share a connection pool with JDBC code and participate in the same transaction.
See the whole section 11.2. Database transaction demarcation and in particular 11.2.2. Using JTA.
What is not clear is if the Hibernate module will be "isolated" from the entities managed via JDBC. If you'll access the same tables via both APIs, you'll have to take some precautions:
don't expect to mix JDBC entities in a graph of Hibernate entities (the inverse is possible though).
respect and mimic Hibernate optimistic concurrency strategy when updating rows via JDBC
bypassing Hibernate's API won't trigger any cache update (if you're using the 2nd level cache) in which case you'd have to trigger it yourself.
Here is one of the possible solutions
A common JNDI Datasource, which will be used both in EJB's and Hibernate.
I am not able to find a way to set TransactionIsolation in ejb. Can anybody tell me how do i set it? I am using persistence.
I have looked the following classes :
EntityManager , EntityManagerFactory, UserTransaction. None of them seems to have any method like setTransactionIsolation or such. Do we need to change persistence.xml?
I just read a book named Mastering EJB 3.0 4th edition. They gave a full 10 page theory about Isolation level that this problems occur and that occurs and such things but at the end they gave this paragraph :-
"As we now know, the EJB standard does not deal with isolation levels directly,
and rightly so. EJB is a component specification. It defines the behavior and
contracts of a business component with clients and middleware infrastructure
(containers) such that the component can be rendered as various middleware
services properly. EJBs therefore are transactional components that interact
with resource managers, such as the JDBC resource manager or JMS resource
manager, via JTS, as part of a transaction. They are not, hence, resource
components in themselves. Since isolation levels are very specific to the
behavior and capabilities of the underlying resources, they should therefore be
specified at the resource API levels. "
What exactly does it mean? What is meant by resource level APIs? Please help me. If persistence has no way to set Isolation Level then why do they give such huge theory in an EJB book and make it heavy in weight unnecessarily :(
As said by EJB specification
Transactions not only make completion of a unit of work atomic, but they also isolate the units of work from each other, provided that the system allows concurrent execution of multiple units of work.
The API for managing an isolation level is resource-manager-specific. (Therefore, the EJB architecture does not define an API for managing isolation levels.)
The Bean Provider must take care when setting an isolation level. Most resource managers
require that all accesses to the resource manager within a transaction are done with the same isolation level.
For session beans and message-driven beans with bean-managed transaction demarcation, the Bean Provider can specify the desirable isolation level programmatically in the enterprise bean’s methods, using the resource-manager specific API. For example, java.sql.Connection.setTransactionIsolation
The container provider should insure that suitable isolation levels are provided to guarantee data consistency for entity beans
Additional care must be taken if multiple enterprise beans access the same resource manager in the same transaction. Conflicts in the requested isolation levels must be avoided.
I hope it can fullfil your needs
See this