File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Hibernate Vs Entity Beans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Hibernate Vs Entity Beans" Watch "Hibernate Vs Entity Beans" New topic
Author

Hibernate Vs Entity Beans

Mary Cole
Ranch Hand

Joined: Dec 02, 2000
Posts: 362
Hi,

Whats the advantage of using Hibernate vs entity beans and vice versa.
Steve Buck
Ranch Hand

Joined: Nov 23, 2004
Posts: 45
Many people dislike using EJBs (which entity beans are a subset of) because they are costly in terms of resources (you will find this many places; I don't have exact numbers but you can easily google for some)

Hibernate is a "lightweight" framework that seems to fulfill the most useful features of EJBs (persistence). It is also much faster because its lightweight.

Your best bet for a comprehensive coverage is to google for some articles.

Personally I stick with EJBs because thats what is in the spec. You can rest assured that if you program to EJB spec, your app will run properly across all application servers (but they must support that EJB spec eg 2.0, 2.1, 3.0 of course).

EJB 3.0 will be more "lightweight" and more like Hibernate from what I've read. It would be advisable to google for EJB 3.0, too.

I've decided that I will stick to EJB because it provides other features I need (remotability, transaction, security, timer services) in addition to being the spec.

It really depends on what sort of functionality and compliance you are looking for. Both are widely used.
[ February 02, 2005: Message edited by: Steve Buck ]
Mary Cole
Ranch Hand

Joined: Dec 02, 2000
Posts: 362
Thx Steve...

I feel HSQL is more matured than EJB QL and simple to use rather than having 3 java files for each EJB.
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336


Personally I stick with EJBs because thats what is in the spec. You can rest assured that if you program to EJB spec, your app will run properly across all application servers (but they must support that EJB spec eg 2.0, 2.1, 3.0 of course).

Of course with Hibernate (or any other simmilar ORM) you don't need an application server for persistance at all. So this is true for Hibernate with all application servers, whether they are spec. compliant or not.


I've decided that I will stick to EJB because it provides other features I need (remotability, transaction, security, timer services) ...

True. But Session Beans provide this too. One (of many!) issues I have with Entity Beans is this needless replication. You can't access an entity bean in any other way than through a session bean. So why do you need the Security etc. stuff defined in both beans? OK may be there might be some special cases but for the vast majority of normal operation this is just needless overhead.

One thing ORM's tend to win out in every time is performance. Entity Beans are a very poor fit for anything other than single entity CRUD operations. Create an application which uses Entity beans where the normal DB operation is a query which returns many results, rather then an update, insert or delete and you will see the overheads.

EJBQL == a sub-set of SQL. This can be a real headache at times. HQL is a more powerful query language, and Hibernate allows direct SQL querioes too.

"Spec. compliance" is not a panacea either. Your code will not be better because it is spec. compliant. In fact, there's a good chance it will be worse.


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Karthik Guru
Ranch Hand

Joined: Mar 06, 2001
Posts: 1209
Hi Paul,

I agree when it comes to simplicty hibernate wins hands down when compared to any cmp solution.


Originally posted by Paul Sturrock:

One thing ORM's tend to win out in every time is performance. Entity Beans are a very poor fit for anything other than single entity CRUD operations. Create an application which uses Entity beans where the normal DB operation is a query which returns many results, rather then an update, insert or delete and you will see the overheads.


Is it because Hibernate cache is better than say weblogic cache?
I guess both must be issuing sqls in the background to fetch the beans. Both can be configured to do a lay load on relationships etc.
If the select returns data that is bigger than the configured cache size what does hibernate do? Weblogic would probably throw a cachefull exception.


EJBQL == a sub-set of SQL. This can be a real headache at times. HQL is a more powerful query language, and Hibernate allows direct SQL querioes too.


So does weblogic, but WL specific QueryLocalHome has to be accessed. The bean/loca/home interface does not have to implement the interface in the code per -se. It just needs to be specified in the descriptor.


 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Hibernate Vs Entity Beans