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
Related
From what I have read so far, Propagation.REQUIRES_NEW makes use of transaction suspension capabilities in most common Java EE containers (JBoss, Glassfish, etc.)
However, as we're running Spring Data inside Vert.x, which is container-less, I'd like to find a definitive answer as to whether REQUIRES_NEW is supported in this scenario, or if we will have to use another approach for this.
You can use Spring #Transactional annotations out of a JavaEE container. It will work well if you only use a database.
If you mix transactional components (a relational database and a message broker) then you need a transaction manager, which is often only available in JavaEE container.
I'm not a Spring or SpringBoot expert but I am pretty sure it's not difficult nowadays to add a transaction manager to a Spring/Tomcat project.
As for running Spring Data in Vert.x, it will work fine if you deploy this code in worker verticles. Check out the spring-worker sample in the vertx-examples repository on GitHub
I read this topic (https://blogs.oracle.com/theaquarium/entry/jta_1_2_it_s) talk about JTA 1.2 can be used without EJB.
So i would like to know if is possible use JTA 1.2 only with CDI within TOMCAT 7 (or lastest version).
Today i'm using DeltaSpike to control my transactions but i would like to change and start using JTA 1.2, because i need "REQUIRES_NEW, SUPPORT and others" that deltaSpike don't have.
Can i use JTA 1.2 without a Server Application like Jboss, Glassfish, TomEE ?
Tomcat doesn't provide JTA because it doesn't have any transaction manager. So the answer to your question is NO.
You can find additional information on how to use JTA in Tomcat here: How to use JTA support in Tomcat 6 for Hibernate?
If you really need JTA, I think it's better to use a full-JEE application server. Else you van also manage the Transaction by yourself.
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 am new to JPA and in many resources of JPA I encounter these two term(Container persistence unit and Non-container persistence unit) but I can not understand differences.Can anybody help me understand these phrases? what is the container ?is it something like
Tomcat?
'Container' in this context means an EJB container, which is usually provided by a Java EE compliant application server.
Since Tomcat is not Java EE compliant, it is not a 'container' in the sense of the JPA spec. Tom EE however provides such a container as do other Java EE servers. Oracle provides a complete list of compliant servers.
The main difference is that in a container you can use JTA resources like transactions and a transaction-scoped EntityManager. Without a container you have to use ÈntityTransaction and an EXTENDED EntityManager.
In the attribute transaction-type can take one of the 2 values "RESOURCE_LOCAL" or "JTA".
JTA - Works on an application server environment. Transaction managed by the application server.
RESOURCE_LOCAL - You managed the transaction with your code. You can use this to work standalone during the development / testing phase.
How can i can achieve remote transaction while using Remote EJB (over RMI/IIOP or RMI/JRMP).
Is that JBoss 4.0 support this kind of transaction or should i use jotm or atomikos?
Thanks in advance
JBoss 4 is a certified J2EE 1.4 application server and thus supports client-controlled transaction which are part of the J2EE specification. In other words, JBoss provides a Transaction Manager, there is no need for a standalone transaction manager like JOTM, Atomikos, etc.
For the record, JBoss default transaction manager is based on Arjuna TS since JBoss 4.2 which is a rock solid technology.
See the chapter 4.2.3. UserTransaction Support for more details.
From jboss.org. This example is from v. 3.2 but I know it works through v. 4.0.3
There is no way to handle transactions from the client without using a TM on the client. The way to design apps is to call services on the server that handle that for you. All J2EE containers that include JTS/JTA (Ones that are more than just web app servers) will support single a two-phase transaction processing.
The client piece should be in charge of just doing presentation and possibly doing calculations as well as they pertain to displaying the data.
if you must use this strategy, go ahead use a Transaction Coordinator (TM) on the client like JOTM or Atomikos or even possibly JBOSS's JBoss transactions.