I'm working on a project that uses Hibernate 4.1, Spring 3.1, and JPA 2.0, and I want to verify that what I've gleaned from the internet is correct.
I'm trying to decide whether to use a JPA entityManager or the hibernate-specific sessionFactory.
At first I planned to use entityManager and full JPA specifications, so my project would be decoupled from Hibernate, and I could switch it out for something else, say EclipseLink, if the fancy took me or something convinced me later on.
However, it seems the entityManager has some very significant limitations.
My questions:
The only reason I would want to use full JPA specifications and the entityManager is to be able to switch out Hibernate for a different JPA 2.0 compatible ORM relatively easily, right? Are there really no performance / functionality / ease of programming benefits to using the entityManager?
Second, it seems like the hibernate sessionFactory has a lot of benefits over the entityManager. So far I've run into the issue that the entityManager can't perform a batch insert of a list of entities, which I've read the sessionFactory can. I've also read that the sessionFactory can return an auto-generated entity ID automatically, while with the entityManager you need to end the transaction / flush the persistence context to pull the newly generated id.
I liked the idea of my project being relatively decoupled from Hibernate, but I would much rather be able to write efficient database updates from the get-go. So I should switch over to my project being configured for hibernate and the sessionFactory, right?
I would stick to JPA2, like you would use List rather than ArrayList: you favour the interface (or abstract) over the implementation. There are not much difference, apart from HQL knowing "more" stuff than JPQL or exotic feature. Also remember that JPA was made after Hibernate, with Hibernate being the "inspiration" behind JPA.
And for exotic feature: Hibernate Entity Manager wrap an Hibernate Session. If you really need them, you can cast the EntityManager to the Hibernate interface (org.hibernate.jpa.HibernateEntityManager), and use that session. But I'd be lying to you if I say I tried it.
I also commented part of your question:
The only reason I would want to use full JPA specifications and the
entityManager is to be able to switch out Hibernate for a different
JPA 2.0 compatible ORM relatively easily, right? Are there really no
performance / functionality / ease of programming benefits to using
the entityManager?
Switching from Hibernate to EclipseLink does not mean you "only need to swap the jar". The mapping, and annotation parsing, is not the same and you'll encounter problems that will probably discourage you from switching.
You can read my question here for an example of a problem I encountered while using both (it was a maven project with a profile to switch JPA2.1 impl from EclipseLink to Hibernate). I dropped EclipseLink because I could not name the database object (or rather, specify the name of database object) like I wanted.
Second, it seems like the hibernate sessionFactory has a lot of
benefits over the entityManager. So far I've run into the issue that
the entityManager can't perform a batch insert of a list of entities,
which I've read the sessionFactory can. I've also read that the
sessionFactory can return an auto-generated entity ID automatically,
while with the entityManager you need to end the transaction / flush
the persistence context to pull the newly generated id.
This depends on how you generate your entity id. But think about it: you entity is not persisted until the persistence context need to persist it. This is the reason you don't have an id. Flushing it, aka sending an insert query with a generated id, is the only way to do it.
The same apply to session factories.
You might however be able to access a sequence generator from Hibernate, but you can also do that in native SQL with EntityManager.
I liked the idea of my project being relatively decoupled from
Hibernate, but I would much rather be able to write efficient database
updates from the get-go. So I should switch over to my project being
configured for hibernate and the sessionFactory, right?
You can take it as a troll against ORM, but for efficient database update, use plain JDBC (or Spring Jdbc Template). At least you'll know when data will be updated, and you'll be able to better optimize (batch update, etc).
JPA is an interface over Hibernate which is an interface over jdbc so the closer you are to jdbc the more control you get over your queries but further you go from object/relational persistence .
Yes, Hibernate may have some tools that jpa may not provide at this moment (i.e hibernate spatial)
Hibernate is fun and can use JPA annotations for mapping the domain model (if you go the annotations way over the .hbm files) . And the way the #Transactional annotation works in Spring it doesnt matter whether you use hibernate or jpa since you dont need session.open() ... session.beginTranscation ...session.close ...etc ... all this verbose Hibernate code is gone!
There is great documentation on Hibernate and greate books as well. As for JPA I cant say that I found the umber book...
Related
I am writing a java application in which I am using Spring Boot and JPA in order to map classes to my database tables.
However, due to a somewhat complex database structure I also have the need of creating custom queries that are not mapped to any specific POJOs / Entities.
Therefore I am using PreparedStatement together with a DataSource with #Autowired annotation.
It hit me that using both of these DB Access methods might not be suitable to use together?
So far everything has worked out in my dev environment, but are there any pitfalls that I should look out for when using both of these together or is there a preferred way of doing custom queries when using JPA?
It should be noted that my database calls are fairly short and happen in a stateless manner, so there should hopefully not be any problems with interfering sessions (?)
JPA EntityManager will not know anything about your changes made with PreparedStatement. This will cause issues with JPA built-in caching, maybe with versioning and also with transaction support.
Though you may need to check this question: Is it OK to use both JPA (for normal CRUDs) and JDBC (for batch update & call stored proc) in the same project
Invan's answer makes a clear point.
On the other hand your fine when:
you need complex queries to SHOW data (read only).
you infrequently need to do some batch updates and do a clear cache entityManager.getEntityManagerFactory().getCache().evictAll()
what we are planning to do is we want a single project but want to use three different frame works to-gather, so is it a good idea or can this is achievable ?
we have already project build up with spring and hibernate but we want to extend it with jdbc template.
please guide on common quetions like
-New Session factory required or not ?
-Can we use pojos with hibernate annotations with jdbc template or we have to create new one ?
-Will this create problem on performance if average is 500 users at a time ?
Thanks in advance.
Using both an ORM and JDBC in the same application is a reasonable thing to do. Hibernate can run native SQL queries so you might consider that as an alternative depending on what you have in mind.
JDBC doesn't use a session factory or entity manager factory comparable to Hibernate. Caching for the JDBC results would have to be handled separately from Hibernate.
The Hibernate/JPA annotations will be irrelevant to JDBC queries, the RowMapper passed into the query controls how pojos get populated. You could re-use your Hibernate entities to be populated by the rowmappers but in practice the reason you use JDBC is to get more focused results with flatter objects and you end up with a separate set of DTOs.
I'm not clear on what you think is going to hurt performance here. JDBC should be an improvement over Hibernate performance-wise, though at the cost of having business-logic spread out in multiple places. The tricky part will probably be setting up the transaction manager so that JDBC and Hibernate use the same transaction, see this question.
I have been trying to use Hibernate for a while. I like hibernate that it has annotation mapping ability (such as #Entity, #Column)
But I don't like it caching idea ( How to disable hibernate caching said that it also cannot be disabled).
Also, I totally don't like its 'commits vs flush' idea which not directly run SQL to database when do insert/delete/update some data in database.
So, as my title, are there any frameworks like Hibernate with annotation but no cache and do directly execute SQL? It would be good if such frameworks can use in Spring.
Or, actually, Can Hibernate just disable cache or just have some configuration that can do direct SQL for every insert/delete/update?
These features are on by default, because you usually need them (even though you don't realize initially).
But if you really want to disable cache and flush everything immediately:
use sessionFactory.openStatelessSession() - this session does not store anything in the 1st level cache (and the 2nd level cache is off by default). Note that you can't operate collection mappings with this session.
use session.setFlushMode(..) to set it to flush automatically before very query (rather discouraged).
Note that the flush mode is available only for stateful sessions - the stateless session is flushed immediately.
Hibernate is a great framework, but for more lightweight implementations I tend to use Spring JDBC:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/jdbc.html
You might be looking for MyBatis, which is a bit more direct. For an annotation-based example, see here although there are others. You can also just use pure JDBC, or via Spring if you're using Spring.
I don't understand the "not liking caching" thing.
In the screen where you can add the Hibernate library to a project, there are two options, Hibernate and Hibernate JPA.
What is the difference between the 2? Googling did not provide an explanation.
I found this to provide a good explanation.
http://elope.wordpress.com/2007/09/06/difference-between-jpa-and-hibernate/
From the above blog:
So if i need to put in Concise words:
a) JPA is Persistence Api which your code should use.
b) JPA Api will pass on the call to actual peristence provider (ex:Hibernate/TopLink) to do the actual work.
c) If you are looking from Performance prespective ,it will be dependent on actual peristence provider (Hibernate/TopLink) and not on JPA as its just a wrapper layer.
d) If you are looking from code dependency prespective ,JPA makes more sense as your code is dependent on standard Java Api.
e) If you have used Hibernate then you will find that certain features are missing in JPA like criteria queries etc.This does not mean that you can’t write criteria query in your application, you need to get Session object from JPA Entity manager and now you are as good as in hibernate project.
But now your code is dependent on Specific impl (Hibernate),going forward you can see more things getting added in JPA (2.0)
f) Should you use JPA: My take is you should ,API is clean and although not everthing you need is their but is a good step forward.
I don't know what "screen" you mean, but in general you can use Hibernate directly (Hibernate API) or as a JPA provider. As JPA is a standard API one can code against this API and switch between implementations (Hibernate, EclipseLink, OpenJPA, ...). When using Hibernate API you are tied to this but you can utilize features that are not standardized by JPA.
I have a large application that uses EJB 2.x entity beans (BMP). This is well-known to be a horrible persistence strategy (I can elaborate if necessary).
I'd like to start migrating this application to use a much more expressive, transparent, and non-invasive persistence strategy, and given my company's previous experience with it, Hibernate 3.x is the obvious choice.
Migrating to Hibernate is going to take a while, as over 100 tables in the application use entity beans. So I'm looking at a phased approach where the two persistence strategies run in parallel, ideally on the same tables at the same time, if possible.
My question is, what are the pitfalls (if any) of combining these two persistence strategies? Will they get in each other's way?
As said jodonnel, you have to pay attention to caching, because if you use second-level caching in Hibernate and a table is modified outside of Hibernate, then Hibernate has no way to know that its cache entry is stale.
For the transactions, they should both use JTA provided by the container, so for that it should be safe.
I guess the thing to really be careful with is working with the Hibernate sessions. Hibernate caches stuff, and that might get in the way.
Frankly I would recommend that if you adopt Hibernate, drop the Entity beans entirely. Do your Hibernate work within session beans and let the session beans manage your transactions.
Or alternately use EJB 3, which is Hibernate standardized into the Java Persistence API.