They recommend using JTA transaction support in Java EE environment.
But how to configure JTA in Tomcat6 so that Hibernate Session could use it ?
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.
(Hibernate Reference Documentation | Architecture. Contextual Sessions)
If you want JTA support in Tomcat you'll need to use a standalone transaction manager like Atomikos, JOTM, Bitronix, SimpleJTA, JBossTS or GeronimoTM/Jencks. But honestly, if you're not going to handle transactions across multiple resources, then you can live without JTA (and if you really need JTA, use a full blown application server).
If you just want to use SessionFactory.getCurrentSession() you can just add the following two lines to your hibernate.cfg.xml:
<property name="transaction.factory_class">org.hibernate.transaction.JDBCTransactionFactory</property>
<property name="hibernate.current_session_context_class">thread</property>
This will give you a unique Session for each thread. As a servlet request is always handled within one thread (given that your code doesn't spawn new ones), the Session will live for the whole request.
Don't forget to use a filter to close the Session after the request!
Related
In my standalone java application, jms and hibernate are used for fulfilling my requirements. I used the JTA transaction manager for the transaction management purposes. Can i enlist the XAResource for the hibernate and jms in the jta transaction to ensure the atomicity of my application.
Yes, it's possible. Called sometimes two-phase commit, it synchronises transactions between multiple resources.
First of all make sure you're RDBMS supports and has the feature turned on. In PostgreSQL, for example, this means setting the max_prepared_transactions configuration parameter from postgresql.conf to something above 0.
Also, make sure the JMS queue you're using support this transaction method. In Wildfly this means adding transaction="xa" on pooled-connection-factory.
I have some confusion on using JTA within the Spring Framework on Apache Tomcat and i hope someone will clarify as after many research i can't seem to find the correct answer as of yet.
I am developing a web application using Spring Framework to be running on Apache Tomcat 6.
I read somewhere that Spring's does support for JTA but it delegates to the underlying JavaEE application server. Now this is where i am confused because i Tomcat is not a full JavaEE application server - it is merely a servlet container and as i believe it doesn't provide JTA implementation like the full JavaEE application server (Glassfish/Wildfly etc...) does.
But when i do something like the following the transaction aspect of it works:
#Transactional
public class ServiceClassImpl implements ServiceInterface {
// code here that involves transactions e.g. calling DAO code
...
}
So, i'm confused. I hope someone will enlighten me.
The answer is: NO.
Tomcat 6.x (7&8) don't provide JTA out-of-the-box because they don't have a transaction manager which is required as a separate component to monitor multiple resources (e.g. datasources).
The mentioned answer How to use JTA support in Tomcat 6 for Hibernate? already gives a list of additional JTA transaction managers that can be used alongside Tomcat.
Spring supports declarative transaction management via a platform transaction manager (TM) and provides some implementations (e.g. datasources) that make #Transactional work on a single resource without the additional TM.
Understanding the Spring Framework transaction abstraction provides more details and Spring Boot can be easily configured to run Atomikos or Bitronix Transaction managers on the embedded Tomcat.
JTA provides you with distributed transactions support, but if JTA is not available like in Tomcat, you still can use local JDBC transactions.
YES :-)
JTA can be used in Tomcat, for instance via https://www.atomikos.com
The trick is to use a componentized JTA implementation.
Cheers
Data Access Layer is not responsible for transaction management am I correct? I have these DAO implementations: HibernateDAO and SqlDAO. If I will choose Hibernate and handle its transaction management at above layer, when I switch to SQL then I will change every single transaction management made by the Hibernate to SQL? This is bad right? What strategy will I gonna use in this case? TIA.
I've never worked on transactions outside of spring and JTA. Spring offers a transactions across several different platforms using transactions. You may want to check that out.
Also, I've seen JTA transactions work on ejb, Hibernate and Jms messages, but not sure if it will work for jdbc and hibernate, more on hibernate transactions here.
Currently I have a spring JMS listener which listens on to an EMS topic and on getting a message processes it and persists it. However, I would like to do all this under one transaction. I am aware this requires XA since there are two global resources which have to register with the Transaction Manager. This can be achieved via JTA that spring provides. However, since my application is standalone, do I require to include a third party JTA standalone implementation like Bitronix or JOTM. I ask this because since both are spring resources, the default JTA should handle this.
Yes you will need to include a third-party TransactionManager implementation that supports XA.
Most application servers e.g. JBoss will bundle an XA TransactionManager of their choice. This is one of the reasons to choose an ApplicationServer over something like Tomcat or a standalone application; the configuration of things like XA transactions is basically done for you.
Sometimes an ApplicationServer is too heavyweight (although I think this is becoming less of a problem) or you can't use one. In this scenario it is your responsibility to provide the TransactionManager implementation if you want to use XA.
You can take your pick from implementations such as: JBossTS, Atomikos Transaction Essentials or Bitronix JTA.
Spring does include a JTATransactionManager implementation. This will either use pre-configured locations to detect the selected XA implementation if you're running in an ApplicationServer, or alternatively you need to configure it yourself if you're in a standalone environment.
There are some excellent resources on configuring an XA TransactionManager with Spring:
http://spring.io/blog/2011/08/15/configuring-spring-and-jta-without-full-java-ee/
http://www.javaworld.com/article/2077714/java-web-development/xa-transactions-using-spring.html
I wan to know how the transaction is internally implemented in EJB. I want to know the logic they use to create a transaction. if you could point out some articles that would be helpful
Hibernate doesn't implement transactions, it relies on and wraps JDBC transactions or JTA transactions (either container managed or application managed).
Regarding EJBs, if you want to understand the details of a JTA Transaction Manager, you'll need to be fluent with the JTA interfaces UserTransaction, TransactionManager, and XAResource which are described in the JTA specification. The JDBC API Tutorial and Reference, Third Edition will also be useful to understand the XA part of a JDBC driver.
Then, get the sources of an EJB container (like JBoss) or of a standalone JTA Transaction Manager (like Atomikos) to analyze the TM part. And good luck.
This question could have answers at many levels.
A general discussion of what's going on can be found here
My summary goes like this ... First, somewhere there must be a transaction coordinator, the EJB container will know about the coordinator - typically that's part of the application server. So all the EJB container has to do is to call
someobject.BeginTransaction()
that's it. The actual API the EJB container uses is JTA. EJBs can actually use Bean Managed transaction transaction or Container managed transactions. In the Bean Managed case the implementer nhas to make the JTA calls. More usually we use Container Managed transactions (CMT). In which case the container has logic which is run before the implementation is reached. For example:
if ( we're not already in a transaction )
begin transaction
call the EJB implementation
and later the container has logic
if ( finished processing request )
commit transaction
with other paths to abort the transaction if errors have happened.
Now that logic is more complex because CMT EJBs are annotated with transaction control statements. For example you can say things "if we already have a transaction, use it" So if one EJB calls another only a single transaction is used. Read up the EJB spec for that.
However all that's pretty obvious in any write-up of Java EE EJBs. So I suspect that you're asking moe about what happens inside the JTA calls, how the transaction manager is implemented and its relationship to the transactional resource managers (eg. Databases). That's a huge topic. You've actually go implementations of the XA distributed transaction protocol down there. Frankly I doubt that you really need to need to know this. At some point you have trust the APIs you're using. However there is one key detail: your Transaction Manager (typically the App Server itself) must be able to tell the REsource Managers the fate of any given transaction, and that information must survive restart of the App Server, hence some persistent store of transaction information must be kept. You will find transaction logs somewhere, and in setting up the App Server you need to make sure those logs are well looked after.
From EJB in Action book
The protocol commonly used to achieve multiple resource is the two-phase commit. The two-phase commit protocol performs an additional preparatory step before the final commit. Each resource manager involved is asked if the current transaction can be successfully committed. If any of the resource managers indicate that the transaction cannot be committed if attempted, the entire transaction is abandoned (rolled back). Otherwise, the transaction is allowed to proceed and all resource managers are asked to commit.
A resource manager can be a database, for instance. Others examples includes a Message Service. The component which coordinates transactions is called Transaction manager.
Suppose you have an application which involves two distincts databases. How does Transaction manager performs its work by using Two phase commit protocol ?
Transaction Manager ask database 1 if it can commit the current transaction
If so, ask database 2 if it can commit the current transaction
Transaction Manager ask database 1 to commit
Transaction Manager ask database 2 to commit
Hibernate is built on top of the JDBC API. It just coordinates one database. So if you call
session.commit();
Behind the scenes, it call
connection.commit();
If you really want to study Transaction internals, my advice is Java Transaction Processing book.
Hibernate has TransactionFactory:
An abstract factory for Transaction instances. Concrete implementations are specified by hibernate.transaction.factory_class.
It has implementations: JDBCTransactionFactory, JTATransactionFactory, CMTTransactionFactory. These factories create an instance of Transaction - for example JDBCTransaction.
Then I can't tell you what happens for JTA and CMT, but for JDBC it's as simple as setting the auto-commit to false (when you call begin a transaction):
connection.setAutoCommit(false);
And respectively on transaction.commit(): connection.commit()
If any exception occurs when operating with the session, it invokes connection.rollback()
Another good read would be the JTS articles by Brian Goetz; links:
http://www.ibm.com/developerworks/java/library/j-jtp0305.html
http://www.ibm.com/developerworks/java/library/j-jtp0410/index.html
http://www.ibm.com/developerworks/java/library/j-jtp0514.html