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.
Related
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
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.
I have a 100% JPA2 compliant application which needs to be portable to many application servers. Being JPA compliant (theoretically) means we can switch JPA providers via configuration (e.g. without changing source code) -- (right???).
When running within a servlet container (e.g. Tomcat, Jetty) the application is configured to run with Hibernate. We choose Hibernate over TopLink and Eclipselink for its maturity and performance. So far this works.
However, when running within a Java EE application server, should we default to the JPA provider therein, or stick with Hibernate?
I know within JBoss, the provider is Hibernate so it probably doesn't matter. However, I think the provider within WebLogic is Eclipselink. I have no idea what the provider WebSphere or Glassfish use, but I have seen detailed instructions on how to use Hibernate as the provider within those application servers.
I guess another way to ask the question is what would we be missing by using Hibernate in these application servers?
I have a 100% JPA2 compliant application which needs to be portable to many application servers. Being JPA compliant (...) means we can switch JPA providers via configuration (...)
Yes.
(...) However, when running within a Java EE application server, should we default to the JPA provider therein, or stick with Hibernate?
Well, if you deploy on a Java EE 6 server, this doesn't really matter. It's not clear who is going to run the application and you can maybe make recommendations but the runtime is actually "not your business" :) Also note that you may not benefit from support if you don't use the default provider (if this matters).
I know within JBoss, the provider is Hibernate so it probably doesn't matter. However, I think the provider within WebLogic is Eclipselink. I have no idea what the provider WebSphere or Glassfish use, but I have seen detailed instructions on how to use Hibernate as the provider within those application servers.
First of all, keep in mind that JPA 2.0 is part of Java EE 6 and that GlassFish v3 is the only one Java EE 6 container at this time. WebLogic and WebSphere are Java EE 5 server, they may not support JPA 2.0.
Now, regarding the default providers:
GlassFish v3 uses EclipseLink 2.0 as default provider but can be configured to use Hibernate 3.5 (through an add-on).
In Weblogic 10.3.2, the default JPA provider is OpenJPA/Kodo and EclipseLink 1.2 is available as a WLS module. In WLS 10.3.3 (not released yet), EclipseLink 2.0 will be available as a WLS module, the default being still OpenJPA/Kodo. But, the container JPA API will still be JPA 1.0! It seems possible to package a JPA 2.0 provider inside your application. See this thread and this page. But this is not officially supported and doing this same thing with Hibernate 3.5 might be another story.
In WebSphere 6 and 7, the default provider is OpenJPA. This link will give you some details about the way to change the default provider (and the consequences). But I can't tell you more.
I guess another way to ask the question is what would we be missing by using Hibernate in these application servers?
As I mentioned, this may not be supported by the vendor. Additionally, if you want to maximize portability and plan to deploy your application in a near future, going for JPA 2.0 is maybe not a wise choice (or too optimistic if you prefer).
I don't see what you will be missing, unless you're using implementation specific API in your JPA code. I.e. do not import org.hibernate anywhere in your JPA code, but just write it against the JPA API.
On the Tomcat FAQ it says: "Tomcat is not an EJB server. Tomcat is not a full J2EE server."
But if I:
use Spring to supply an application context
annotate my entities with JPA
annotations (and use Hibernate as a
JPA provider)
configure C3P0 as a connection pooling data
source
annotate my service methods
with #Transactional (and use Atomikos
as JTA provider)
Use JAXB for marshalling and unmarshalling
and possibly add my own JNDI capability
then don't I effectively have a Java EE application server? And then aren't my beans EJBs? Or is there some other defining characteristic?
What is it that a Java EE compliant app server gives you that you can't easily/readily get from Tomcat with some 3rd party subsystems?
EJBs are JavaEE components that conform to the javax.ejb API.
JavaEE is a collection of APIs, you don't need to use all of them.
Tomcat is a "partial" JavaEE server, in that it only implements some of the JavaEE APIs, such as Servlets and JNDI. It doesn't implement e.g. EJB and JMS, so it's not a full JavaEE implementation.
If you added some additional bits and pieces (e.g. OpenEJB, HornetQ), you'd add the missing parts, and you'd end up with a full JavaEE server. But out of the box, Tomcat isn't that, and doesn't try to be.
But if I add (...) then don't I effectively have a Java EE application server? And then aren't my beans EJBs? Or is there some other defining characteristic?
No, you don't have a Java EE application server, a full-fledged Java EE application server is more than Tomcat + Spring + a standalone Transaction Manager. And even if you add a JMS provider and an EJB container, you still won't have a Java EE server. The glue between all parts is IMO important and is part of the added value of a Java EE container.
Regarding EJBs, the EJB specification is much more than JPA and specifices also Session Beans and Message Driven Beans (actually, I don't really consider JPA Entities as EJBs even if JPA is part of the EJB 3.0 specification in Java EE 5 for historical reasons - which is not true anymore in Java EE 6, JPA 2.0 and EJB 3.1 are separate specifications).
I should also mention that a Spring bean annotated with #Transactional is not equivalent to a Session Bean. A Java EE container can do more things with Session Beans (see below). You may not need them though but still, they are not strictly equivalent.
Last thing, Java EE containers implement a standard, the Spring container does not, it is proprietary.
What is it that a Java EE compliant app server gives you that you can't easily/readily get from Tomcat with some 3rd party subsystems?
As I said, I think that the "glue" is a part of the added value and highly contributes to the robustness of the whole. Then, ewernli's answer underlined very well what is difficult to achieve. I'd just add:
Clustering and Fail-over (to achieve fault-tolerance)
Administration facilities
Yes, a good Java EE server will do pretty neat things to improve fault tolerance (clustering of connection pools, JNDI tree, JMS destinations, automatic retry with idempotent beans, smart EJB clients, transaction recovery, migration of services, etc). For "mission critical" applications - the vast majority are not - this is important. And in such cases, libraries on top of the Servlet API are IMO not a replacement.
1) You're confusing JPA entities with EJBs. While JPA belongs to the EJB3 specification, it was always meant to be a standalone technology.
2) EJBs are: stateless beans, stateful beans and message driven beans. While each of these functionalities can easily be achieved using spring, spring just does not use this terminology. In Spring, you don't have POJO + "magic" as in EJBs, in Spring it's POJO + your own configuration (which sometimes feels like magic, too). The main difference is that spring does more and the application server does less, which is why a spring app is happy with a tomcat while an ejb3 app needs a 'real' application server.
In my opinion, 90% of applications can be deployed using spring + tomcat, ejb3 is rarely needed.
Indeed, if you put enough effort you can almost turn Tomcat/Spring into a full-fledged heavyweight application server :) You could even embed a portable EJB3 container...
What is it that a Java EE compliant app
server gives you that you can't
easily/readily get from Tomcat with
some 3rd party subsystems?
There are still a few features that are hard to get with 3rd party modules:
stateful session beans (SFSB)
extended persistence context
application client container / java web start
clustering depending on the app. server
CORBA interoperability
JCA integration ~
remoting ~
container-managed transactions ~
decent management of distributed transactions (e.g. recover heuristic tx)
Entries with ~ are also supported by Spring, but not so trivially, at least to my best knowledge.
A few more details in this answer: EJB vs Spring
Outside of the strict definition of what is and isn't an EJB, you're adding a lot of stuff to Tomcat. Even if what you have is an EJB server, it's not really plain Tomcat anymore.
The FAQ is correct: Tomcat is not an EJB server. However, it can be that or many other things if you pile on enough extra libraries and code.
An EJB implementation would be a bean written and packaged to run on any compliant EJB server. If you do what you describe, it may work, but it won't be portable to another vendor's application server.
So EJB is a standard that adheres to a specific specification and is therefore portable.
In practice many EJB's are not fully compliant or application server neutral. However, in the main they are, so the small incompatibilities would be much easier to fix if you changed application server vendors than attempting to move the architecture you described to a GlassFish, JBoss or Weblogic server.
EDIT: In response to your comment you would not have an EJB appropriately annotated and/or configured via XML in such a way that code that accessed it in EJB compliant ways would be able to use it without changes.
There are two angles to your comment. One is what functionality would you lose deploying on a JBoss or any of the others instead of Tomcat? Likely nothing, if you brought along all of the frameworks you relied on. However, if you wanted to move your code to Weblogic, for example, to use some of its features, then your code would need some likely significant changes to keep up.
I am not saying that you cannot replicate all EJB functionality (certainly the subset you care about) via other means, just that it is not the spec, and therefore not implementation independent.
then don't I effectively have a Java EE
application server? And then aren't my
beans EJB's? Or is there some other
defining characteristic?
Quick answer EJBs actually have to follow a Java EE specification. Tomcat is a Java EE container not an app server.
What is it that a Java EE compliant app
server gives you that you can't
easily/readily get from Tomcat with
some 3rd party subsystems?
Quick answer to your second question. In your case most likely nothing.
EJBs tend to be really heavy objects and people ended up using them to solve problems when they were essentially overkill. Frameworks like Spring were created to solve those problems without using EJBs. I think the first book where Spring was introduced was even called "J2EE development without EJB."
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.