I have been using #Transactional on my spring boot application for transaction management. But today someone told me to use narayana for transaction management.
Why do I have to use narayana if spring itself can do transaction management for me.
There are basically two kind of transaction. Local transactions are specific to a single transactional resource like a JDBC connection, whereas global transactions can span multiple transactional resources like transaction in a distributed system.
If you need transaction management for distributed system, spring transaction management is not sufficient and narayana will come into play.
From Spring boot docs:
Spring Boot supports distributed JTA transactions across multiple XA
resources by using either an Atomikos or Bitronix embedded transaction
manager. JTA transactions are also supported when deploying to a
suitable Java EE Application Server.
When a JTA environment is detected, Spring’s JtaTransactionManager is
used to manage transactions. Auto-configured JMS, DataSource, and JPA
beans are upgraded to support XA transactions. You can use standard
Spring idioms, such as #Transactional, to participate in a distributed
transaction. If you are within a JTA environment and still want to use
local transactions, you can set the spring.jta.enabled property to
false to disable the JTA auto-configuration.
Related
The jboss narayana jta transaction manager is implemented in my standalone java application. can i integrate the transaction manager from jta to the hibernate. when i invoke the commit method of the jta transaction manager, all the changes done by the hibernate should also be commited. Pleaes help with example.
Yes, you can use the narayana integrated with the hibernate. The most important is that you have to provide a TransactionalConnectionProvider to work with the transaction manager. We have an example for this and you can find Standalone JTA with Hibernate example
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.
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.
Quote from hib official docs:
Starting with version 3.0.1, Hibernate added the SessionFactory.getCurrentSession() method. Initially, this assumed usage of JTA transactions, where the JTA transaction defined both the scope and context of a current session. Given the maturity of the numerous stand-alone JTA TransactionManager implementations, most, if not all, applications should be using JTA transaction management, whether or not they are deployed into a J2EE container. Based on that, the JTA-based contextual sessions are all you need to use.
end of quotation
I use tomcat6 as a servlet container, and need to integrate Hibernate 3.2 into the project.
I found a document how to configure SessionFactory lookup through JNDI, though it does not work as expected.
Quote:
Hibernate works in any environment that uses JTA, in fact, we recommend to use JTA whenever possible as it is the standard Java transaction interface.
End of quote.
In hibernate config I indicate current_session_context_class = jta
and now I get an error "No TransactionManagerLookup specified".
The problem is that Tomcat does not support JTA, and to get it worked,
if I understand it correctly,
you need to add JOTM or other library to Tomcat.
But according to quote it is recommended to use JTA.
What can you recommend in this situation?
Your choices are pretty clear:
Either change to a servlet container that does support JTA
Find another transaction mechanism other than JTA, such as programatically controlling transactions yourself.
What can you recommend in this situation?
Do without JTA and use the Open Session In View pattern to handle the session.