EJB vs. Hibernate

[Hanna Habashy]

Hello all:

We are about to start a new project, and I am looking for a scalable and rubust framework. I have some experience with Hibernate 2.0, and I like it. I don't have work experienc with EJB, however I read Head First EJB about 3 years ago, and I was not fond of it, because it was too complix.
I read good things about EJB 3.0, and I want to hear about your experience and review.

I am considering EJB, Hibernate, or plane DAO pattern. The only thing I don't like about Hibernate is performace. DAO requirs a lot of coding. What do you think about EJB 3.0?

Your feedback is appreciated.

[Paul Sturrock]

The only thing I don't like about Hibernate is performace

Anything in particular? In my experience, most ORM's perform pretty much the same. I've not noticed anything about Hibernate that worries me.

DAO requirs a lot of coding.

Then I would recommend a code generation tool. Many modelling tools (such as Together, or the Hibernate tools plugin for eclipse) will automatically generate DAO based on your model or mapping files.

[Merrill Higginson]

I'd like to clarify one thing about EJB 3.0: It's a specification that requires a persistence provider. The main ones I'm aware of are TopLink and Hibernate. So, if you decide to go with EJB 3.0, it's likely you'll want to select Hibernate as its underlying persistence provider.

Another option you may not be aware of: Java Persistence API (JPA) can be used independently of EJB 3.0. You could simply use JPA within your web container or GUI client without using EJBs.

[Hanna Habashy]

Anything in particular? In my experience, most ORM's perform pretty much the same. I've not noticed anything about Hibernate that worries me.

For the small application that I used Hibernate for, I didn't not notice any performance issues. Currently, we have a software vendor who is developing a large scale application. The vendor is using Hibernate 3.1. Peridically we do performance testing and tuning, and the result is not so good. I searched the web for Hibernate perforamce benchmarks and tunning, and I found that large number of people complains about the performace. Nonetheless, our system adminstrator and DBA are not keen on using Hibernate. They worry about performance issues as well.

Then I would recommend a code generation tool. Many modelling tools (such as Together, or the Hibernate tools plugin for eclipse) will automatically generate DAO based on your model or mapping files.

I will look at it. Thank you for recommending it.

[Hanna Habashy]

I'd like to clarify one thing about EJB 3.0: It's a specification that requires a persistence provider. The main ones I'm aware of are TopLink and Hibernate. So, if you decide to go with EJB 3.0, it's likely you'll want to select Hibernate as its underlying persistence provider.

Another option you may not be aware of: Java Persistence API (JPA) can be used independently of EJB 3.0. You could simply use JPA within your web container or GUI client without using EJBs.

Good point, thank you

[Mark Spritzler]

Peridically we do performance testing and tuning, and the result is not so good. I searched the web for Hibernate perforamce benchmarks and tunning, and I found that large number of people complains about the performace. Nonetheless, our system adminstrator and DBA are not keen on using Hibernate.

It is very possible that the vendor did not try to performance tune their app. There are many tuning possibilities in Hibernate, and there are many traps you could fall in if you are not careful. Some people load too much data for the use case that they are solving and that reduces performance. Some always do lots of roundtrips to the database.

There is a lot to Hibernate and I find them incredible. If you went the JDBC route your costs will be higher because you will have to write more code and also will be tougher to maintain.

Mark

[Paul Sturrock]

Originally posted by Hanna Habashy:

For the small application that I used Hibernate for, I didn't not notice any performance issues. Currently, we have a software vendor who is developing a large scale application. The vendor is using Hibernate 3.1. Peridically we do performance testing and tuning, and the result is not so good. I searched the web for Hibernate perforamce benchmarks and tunning, and I found that large number of people complains about the performace. Nonetheless, our system adminstrator and DBA are not keen on using Hibernate. They worry about performance issues as well.

This sort of evidence would still be a bit too vague for my liking. Almost all performance issues are specific to the particular scenario, so I'd recommend trying some testing yourself. Writing a basic Hibernate application is easy, tuning one is much more involved (like Mark says, there is a lot that can be done). I'm sure your DBA would not suggest that queries run against a database just perform well without any other invovement or tuning. With Hibernate too, if you find a place where you just have to use native SQL, you can. Equally, you can use it to call stored procedures, which, your DBA will probably tell you, is the usual suggestion for very quick database performance (since all the logic is not entirely in the domain of the DBA).

[vu lee]

There is a lot to Hibernate and I find them incredible. If you went the JDBC route your costs will be higher because you will have to write more code and also will be tougher to maintain.

This is quite true, but writting more code is not neccesarily bad. Sometimes, I refer to know (1) what I'm doing (2) how I get from A to B (3) which path I will take from A to B.
Wouldn't the DBA's job is to figure out the is the best/optimal SQL to use for a given db server?

Sometimes, I avoid using generic algorithm to solve specific problem.

I do use Hibernate, but only for certain applications
[ February 16, 2007: Message edited by: vu lee ]

[Mark Spritzler]

Originally posted by vu lee:


This is quite true, but writting more code is not neccesarily bad. Sometimes, I refer to know (1) what I'm doing (2) how I get from A to B (3) which path I will take from A to B.
Wouldn't the DBA's job is to figure out the is the best/optimal SQL to use for a given db server?

Sometimes, I avoid using generic algorithm to solve specific problem.

I do use Hibernate, but only for certain applications

[ February 16, 2007: Message edited by: vu lee ]

Writing more code just means there is more for you to maintain. 80% of your apps costs are in maintenance, less code does reflect in your costs.

In your assumption about best/optimal SQL and a DBA, does not necessarily mean that the guys who created Hibernate were not DBAs, that they do not know the best/optimal SQL for specific vendors, and that DBAs in a particular vendor are all the best in the world.

I know the guys who developed Hibernate, and they have so many years of database experience, and work very hard in knowing vendors specific SQL so that they know what is the best/optimal SQL for lots of vendors, and that you or me as a developer in JDBC, should know as much.

There is also an assumption in your statements about how much Hibernate controls, and how much (all of it) you can actually control when you map, write queries, and keep track of caching. You have complete control over it all in Hibernate, if you want.

Unfortunately, for a tool like Hibernate, that has so much to it, it takes a while to really see everything that it has, and it is easy to make assumptions on areas which you haven't covered yet in Hibernate, I do that too. But once you get over the learning curve, you will see that there really isn't any better way to write your database-driven applications in Java than with a really good and powerful ORM tool like Hibernate.

Mark

[Hanna Habashy]

Mark:

Thank you for sharing your knowledge.
Our DBA/Architect wants to implements all the SQL query in stored prodedure.

Is is a good idea to use Hibernate with almost 100% stored prodedures?

Thanks

[Mark Spritzler]

Originally posted by Hanna Habashy:
Mark:

Thank you for sharing your knowledge.
Our DBA/Architect wants to implements all the SQL query in stored prodedure.

Is is a good idea to use Hibernate with almost 100% stored prodedures?

Thanks

Yes it is possible. You can change the exact SQL statements that are run for all CRUD operations, like sql-insert, sql-delete, and sql-update. There is also a <loader> tag that can give you the general Select statement to load an object, these can all call Stored Procedures. There are some caveats with stored procedures, and it also depends on the database vendor and which driver you use. For instance, if you have Oracle and use the driver made by Oracle, then you can only have one out parameter, and it must be the first parameter and it must be a Reference Cursor. This is because Oracle's own JDBC Driver is not 100% JDBC API compliant. Wow, imagine that Oracle doing something their own way.

I highly recommend getting the Manning Press's "Java Persistence with Hibernate" book. It has a really good section on stored procedures.

Also let the DBA read this book.

Mark