I am using Hibernate to map objects to entities and I have started to use an Entity Manager. This might be a silly question but what actually is the reason for using the entity manager? Previously I would have used a HibernateSessionFactory to get a session and then use that session to pull/push data.
Because the EntityManager is part of the standard - JPA. Theoretically, you can switch implementations (Hibernate, EclipseLink, OpenJPA) if you need to. Apart from alleged portability there isn't such a big difference between the two.
Hibernate implements the JPA standard. In fact, the EntityManager has a delegate, based on the concrete implementation. For Hibernate the delegate is the Session. If you call getDelegate() it will return the current Session.
I've always used hibernate with JPA (EntityManager) and had very rarely had the need to obtain the Session.
EntityManager is a concept of JPA.
You dont need to use JPA with Hibernate at all (in fact, if it's JPA1, I would suggest you dont).
You use an EntityManager when you are using JPA API. Hibernate implementation of EntityManager internally calls HibernateSessionFactory and manages Hibernate sessions for you.
EntityManagers in JPA serve basically the same purpose as Hibernate sessions.
Related
I am just learning JTA and can't understand if I should use it if I have only one database. Currently I use hibernate 5 as JPA provider and if I need to use one transaction between methods I just pass EntityManager as argument.
However, I don't like this method as I need to remember if transaction is opened or not. I would like to find any library that will help me to control transactions (but without Spring) in SE environment. So, should I use JTA in my situation or should I use something different?
Normally when talking about JTA , it refers to the distributed transaction across multiple systems (e.g. across two databases , one database and one JMS compliant message broker). If you only have one database , it is not necessary to use JTA transaction although it should also work. Instead, use a local transaction for one database which should theoretically faster than using JTA transaction.
On the other hands , if you are just talking about #Transactional defined in the JTA , which allow you to declaratively control the transaction boundary by annotating it on a method and without passing the EntityManager between methods , you should look into which frameworks support it.
Under the cover , a proxied EntityManager is injected into different classes such that when it is invoked , it will get the actual EntityManager from the ThreadLocal. So every class in the same thread will get the same EntityManager which prevent you from passing the EntityManager around the methods. A new EntityManager instance will be set to the ThreadLocal just before the #Transactional method is executed using some sort of AOP technique.
Please note that #Transcational is nothing to do with the underlying transaction is JTA or local transaction. It should work for both transaction type.
I would use a framework that support #Transactional such as Spring , Quarkus or Micronaut etc , and configure Hibernate to use local transaction but not JTA transaction for single database.
I'm developing a JPA provider that uses Mongo Driver.
I know that there are Mongo providers for JPA but I need to have more control in what's happening. I reached the point where I need to create a mechanism to synchronize JPA and JTA (Narayana), but I'm not sure how can I do it, I know that javax.transaction.Transaction has method where you register a javax.transaction.Synchronization that has two methods beforeOperation and afterOpertation. So my question is,
where do I perform my CRUD operations where do I call the commit of JPA when JTA commit is called? Should I perform the operations on those methods?
Thank you for your help and time.
Hibernate has a Stateless Version of its Session: Does something similar exist for the JPA EntityManager? I.e. an EntityManager that does not use the first level cache?
From JPA point of view:
javax.persistence.EntityManager stands for 1st level cache (persistence context, transactional cache)
javax.persistence.EntityManagerFactory stands for 2nd level cache (shared cache)
A given persistence provider may implement additional caching layers. Additionally JDBC Driver API may be treated as low-level cache for storing columns/tables and caching connections/statements. It's however transparent to JPA.
Both javax.persistence.EntityManager and org.hibernate.StatelessSession offer similar APIs.
You cannot disable 1st level cache with EntityManager beacuse these two things are equivalent. You can however:
skip 1st level cache by using createQuery, createNamedQuery, createNativeQuery for querying and bulk updates/deletes (the persistence context is not updated to reflect their results). Such queries should be executed in their own transaction thus invalidating any cached entities, if any. Transaction-scoped entity manager (means stateless) should be used as well.
disable 2nd level cache by setting up <shared-cache-mode>NONE</shared-cache-mode> in persistence.xml or javax.persistence.sharedCache.mode in properties
Not part of the JPA API or spec. Individual implementations may allow disabling the L1 cache. DataNucleus JPA, the one I have used, does allow this
On an interface point of view, RDBMS usually respect the ACID constraints, a stateless option would be very specific. I guess this is the reason why Hibernate proposes this feature but not the specification.
To disable the cache, you have implementation-specific configurations (here is the doc for EclipseLink). The #Cacheable annotation (JPA 2.0) at the entity level is standard.
But if you would like to perform bulk operations, this would not do the job. Anyway, such a behavior would be implementation-specific.
I am new to JTA and I need a method to retrieve some some elements from the database. I can do this through EntityManager but that works only for ResourceLocal.
I want to know how can I do this:
Query q = em.createNamedQuery("AnyQuery");
q.getResultList();
without the use of EntityManager.
Any ideas?
The question itself shows that you don't understand any of the technologies you try to work with. You probably need to study some more general stuff before you do any actual development.
you are probably confusing JTA and JPA,
your statement about RESOURCE_LOCAL is not true (and irrelevant) - there are JTA and RESOURCE_LOCAL transactions and in Java EE you usually use the former,
your thought of using Named JPA queries without EntityManager is plain absurd and probably stems from misunderstanding of some kind (what would be the point of using named queries without an entity manager?),
saying "some elements from database" shows that you can't really tell the difference between records and mapped objects, in which case you probably should not use JPA at all.
I am not really expecting that you accept this answer. That's just my frustration taking over.
EDIT
OK, now that you mentioned JSF I understand more of your problem.
I assume you want to use JPA. In such case you have a choice of:
creating your own EntityManager (in such case you cannot have it injected; instead you have yo use an EntityManagerFactory and build your own). This is an "application managed EntityManager". You don't really want to do this.
using an injected EntityManaged ("conatiner managed EntityManager"). This is the standard choice.
Now you need a transaction. Since you should be using a JTA EntityManager, you will need a transaction object that is responsible for coordinating the whole thing. Again, you have two choices:
in a JSF bean, inject a UserTransaction (using #Resource annotation). This is messy, error-prone and takes a lot of boilerplate, but you will find all the necessary methods. You can create your own (application managed) EntityManager, call its joinTransaction method and then call begin-commit on UserTransaction. This is would be an "application managed transaction"
move your EntityManager code to EJB. It only takes a couple of lines of code and a single annotation (#Statless). All the code inside an EJB is - magically - wrapped inside a transaction that the container manages for you. This is the "container managed transaction" - the default and common choice.
Each of the things above could (and should) be expanded with some additional information. But the short path for you is:
create an EJB (a simple class with #Stateless annotation),
move the method that uses EntityManager to the EJB,
inject the EJB into your managed bean (using #EJB annotation) and call the relevant method.
The JTA transaction will happen around each call to any EJB method. This should get you started :-)
Title says it all: What is the difference between a UserTransaction and an EntityTransaction?
My rudimentary understanding is that UserTransaction is used when JTA is required (e.g. to do queries on mulitple things), and that EntityTransaction is used when JPA only is required (e.g. when the query is atomic).
Is that the only difference between the two or is there more to it than that?
My rudimentary understanding is that
UserTransaction is used when JTA is
required (e.g. to do queries on
mulitple things), and that
EntityTransaction is used when JPA
only is required (e.g. when the query
is atomic).
That's basically right, but your description of "multiple things" and "atomic" is a bit strange. JTA allows the developper to use distributed transaction to perform changes on multiples resources (database, JMS broker, etc.) atomically (all-or-nothing). If only one resource is accessed (e.g. one single database), you don't need JTA, but the transaction is still atomic (all-or-nothing). That's for instance the case when you use a regular JDBC transaction on one database.
Considering UserTransaction vs. EntityTransaction:
If JPA is use stand-alone, you use EntityTransaction to demarcate the transaction yourself.
If JPA is used within a managed environment where it integrates with JTA, you use UserTransaction. The EntityManager hooks itself into the JTA distributed transaction manager. The only subtlety I'm aware of considers the flush of the changes. When EntityTransaction is used, JPA know it needs to flush the changes. If transaction are controlled using UserTransaction, it needs to register a callback using JTA registerSynchronization, so that the changes are flushed to the database before the transaction completes. If you use EJB with CMT (container managed transaction), you don't even need to use UserTransaction: the app server starts and stops the transactions for you.
Related questions:
What is difference between UserTransaction and EntityManager.getTransaction() (duplicate)
XA and non-XA datasource with Spring/Hibernate (related)