Spring Hibernate and JDBC Template in a Single Project - java

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.

Related

JAVA - Bad practice to use both JPA and PreparedStatements?

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()

Join without mapping entities in spring

Am not that good yet with spring. Before now I thought its unprofessional to build an application with spring without using hibernate ORM. Until yesterday when I spent a full day trying to execute a "ManyToOne" mapping. Then I came across some threads where I got to know that u should only use hibernate with spring if only u need ORM in your application. That jdbc template will suffice should you not need ORM. Now my question is do I still need relational mapping to execute JOINS in SPRING using JDBC TEMPLATE(without using hibernate at all)
Spring JdbcTemplate allows you deal with native Java driver to work with databases, writing less code than using it directly. As you have guessed, it is a good option when the performance is more important than build a robust application using the "easy way" that brings you an ORM like Hibernate for example.
Answering your question, if you are talking about the Hibernate annotations like #ManyToOne or similar, the answer is no. Using JdbcTemplate you won't need them. However, you will need to specify in every query what are the required columns of every table and the columns of the related ones that you will want to get.
The following links give you some examples about how to deal with JdbcTemplate and joins:
Example 1
Example 2
More information about JdbcTemplate here

Use hibernate sessionFactory or JPA entityManager?

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...

Are there any frameworks like Hibernate but no cache and do directly execute SQL?

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.

Spring vs Hibernate

Just trying to get my head round Spring and figuring out how I wire up an Oracle connection in xml config file, and now find out I need yet another framework! - Hibernate, this is soooo frustrating as it feels like I'm getting deeper and deeper into more and more frameworks without actually getting what I need done!
I looked at Hibernate and it seems to do similar things to Spring, bearing in mind I just want to do some SQL inserts in Oracle.
I am reluctant and do not have time to learn 2 frameworks - could I get away with just adopting Hibernate for the simple things I need to do?
...could I get away with just adopting Hibernate for the simple things I need to do?
Yes
Hibernate is for ORM ( object relational mapping ) that is, make your objects persistent to a RDBMS.
Spring goes further. It may be used also as a AOP, Dependency Injector, a Web Application and ORM among other things.
So if you only need ORM, just use Hibernate. Time will come when you need Spring, and you will learn it then.
Here's an architectural view of Spring:
And this is Hibernate:
Spring and Hibernate are totally different frameworks for different problems. Spring is a huge framework with many many features, Hibernate is an O/R bridge.
I would recommend using plain old JDBC in your case ('just some SQL inserts in Oracle').
You could get away with using just spring and spring-JDBC integration. Depending on the complexity of your data-access needs it may be more than enough. The spring Object-relation mapping is also worth looking into if you're going to do a lot of data-access.
The nice thing about spring is that it's a very loosely coupled framework. So you can read up on the bits you use, and forget the rest - even in the runtime.
Spring and Hibernate are really intended to do two different things. Spring is first and foremost an inversion-of-control container and configuration subsystem, while Hibernate is a database binding and lazy loading engine. If you don't want to introduce a bunch of new stuff into your code, stick with Spring and roll your own queries or use iBatis to do much simpler database binding.
If all you want is insert sql for oracle I would stick to a simple JDBC library. All you need is a Connection and maybe some ConnectionPool (maybe c3po). Hibernate and the like are too big/too complicated and IMO inferior. Hibernate incorporates JDBC under the hood but in every measurable way is inferior -- harder to use, not faster, and the queries you have to write or not any easier. It is also a testament to their inferiority because HQL also provides a bypass route so you can enter JDBC queries directly. They provide this (I suspect) because for any complex query you simply can't construct it well in HQL.

Categories