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.
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.
I have a local application (no JEE server) that shall use postgres at the end.
I'd like to chose Hibernate as my database framework. I'm now creating the persistence.xml, and wonder which transaction-type I should chose: JTA or RESOURCE_LOCAL, or none?
<persistence-unit name="travelport" transaction-type="JTA">
Further I'd like to use the Hibernate EntityManager in my application. Can I have my application manage the transaction itself somehow (any framework)? Or do I always have to open, commit and close the transactions myself when not using an application server?
You really only need the JTA transaction type if you're running in an EE environment, so definitely choose RESOURCE_LOCAL.
As for transaction management, have a look at Spring Transaction Management - I won't repeat the good examples in that link here, but feel free to post follow-up questions if needs be :-)
And don't forget DB pooling as well (DBCP, C3P0 etc).
Cheers,
For a SE application, you should use RESOURCE_LOCAL and manage the transaction by yourself.
Automatic transaction management would require the beans/services to have a managed lifecycle and a possibility to plug in into that lifecycle.
I am not aware of a readymade lifecycle framework for Java (Spring is a good option for servlet containers, but be aware of all the goods it brings to the table in addition to the bean lifecycle).
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.
Is it correct to say that using JTA Transactions with Hibernate contrasts using the Open-Session-In-View with regards to the session scope?
From what I've been able to gather the Session scope in the JTA Transactions is a transaction (mainly based on this link) while in the Open-Session-In-View pattern the session's scope is the requrest and you can have multiple transactions in it.
I'm asking, first to understand, and secondly to verify "Who" is responsible for the session handling when using JTA.
Currently, when using the Open-Session-In-View, I have a HibernateUtil class which handles opening, retrieving and closing of sessions (via ThreadLocal<Session>).
When I'll switch over to using JTA will Hibernate handle the above session actions? (as a derivative maybe of my calling userTransaction.begin,userTransaction.rollback)
BTW, I'm asking about JTA as I need to coordinate a transaction across Hibernate JMS and EHCache so this isn't a general best-practices "lets-use-JTA" question.
Ittai
Well, if you're using JTA then the JTA manager (usually EJB3 container) is responsible for transactions.
Typically, the same good old open-transaction-in-view model is used, however with UserTransaction and, say, a SWING client it's possible to have long-lasting transactions spanning multiple requests (though it's a bad practice in general).
BTW, I'm asking about JTA as I need to coordinate a transaction across Hibernate JMS and EHCache so this isn't a general best-practices "lets-use-JTA" question.
Good luck. I found that external transaction manager (I've used Atomikos) + Spring worked better for my needs than JBoss.