• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Hibernate Vs Entity Beans

 
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Whats the advantage of using Hibernate vs entity beans and vice versa.
 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 362
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thx Steve...

I feel HSQL is more matured than EJB QL and simple to use rather than having 3 java files for each EJB.
 
Bartender
Posts: 10336
Hibernate Eclipse IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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.
 
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.


 
Think of how dumb the average person is. Mathematically, half of them are EVEN DUMBER. Smart tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic