Sometimes you might want to use JPA in JavaSE, when there is no UserTransaction available (you could use JOTM or other implementations, but sometimes this is not an option). This is the point when EntityTransaction comes in handy.
Even if there is a UserTransaction available, we can get an EntityTransaction by invoking the EntityManager.getTransaction() method. So, if we rollback the EntityTransaction, do it commit the active UserTransaction too?
I couldn't understand how EntityTransaction interacts with the UserTransaction (or any other JTA Transaction), when both are used in the same method.
They don't interact. You either use a JTA (UserTransaction) or resource-local (EntityTransaction) persistence manager. When your manager is resource-local, and you still use a UserTransaction for some other resources, the persitence manager is not part of the UserTransaction, so any commit / rollback on EntityTransaction doesn't influence the UserTransaction.
This is what I think: UserTransaction and EntityTransaction has no any communication within each other. EntityTransaction can be use anywhere, even though a UserTransaction is used or not. If we don't need to use EntityTransaction, and if we need to use UserTransaction for the EntityManager, we jave to use the joinTransaction() method. After the invocation of that method, the EntityManager uses the UserTransaction instead of EntityTransaction. In this case, EntityManager.getTransaction() returns null.
Not really. You choose transaction type when you configure your persistence unit, you can't switch it later or even choose between them. When your entity manager is JTA, getTransaction() throws IllegalStateException. Generally (as the specs say), in an EJB container you should use UserTransaction, and use EntityTransaction in JavaSE when no transaction manager (JTA) is available. UserTransaction is required in JavaEE environments, and there is really no advantage to use EntityTransaction in EE (at least I think so).
UserTransaction is required in JavaEE environments, and there is really no advantage to use EntityTransaction in EE
Assume there's a transactional business method. Futhermore assume there is some logging in the business method that writes information in a log db. Of course the log entries should be persisted independently from the completion of the business transaction.
How do you solve this requirement using only UserTransactions ??
It can be easily solved using an EntityTransaction for the logging issue and a JTA transaction for the business transaction.
Ralph, I agree with the example. That's why I wrote "at least I think so" at the end of the sentence you so selectively quoted. I couldn't think of any example at the time I was writing it, but what you came up with is clearly a good one. However, this would require another persistence unit configuration, right? It would have to be resource-local.
BTW, maybe you tested it - the specs on page 150 list 4 standard properties, one of which is javax.persistence.transactionType. Suppose we have our unit configured to be JTA, and then, in code, we want to switch it to be resource-local, and we know that we can pass our own map to the factory methods, or use PersistenceProperty elements of PersistenceUnit / Context. Does it work? I mean, suppose I specified the property value to be RESOURCE_LOCAL, will the persistence context be resource-local?
sorry, if my quoting was/is too selective. I meant no harm by it.
However, this would require another persistence unit configuration, right? It would have to be resource-local.
Yes, you would need a second persistence unit in the persistence.xml file that uses transaction type RESOURCE_LOCAL (the other one has transaction type JTA) and in the bean there'll be two different entity managers, respectively.
Think for example of a bean that processes stock orders from online brokerage. If something goes wrong, the customer complains at his bank that he can't order and the bank employee asks the IT departement what happened. What will you say to him ? In such a situation it's quite helpful to have some information (db not available, stock id not found, wrong risk class, etc.).
SCJP 5 (98%) - SCBCD 5 (98%)
World domination requires a hollowed out volcano with good submarine access. Tiny ads are optional.
Free, earth friendly heat - from the CodeRanch trailboss