• 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

Use of Entity Beans?

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi folks,
I realy need help wth this one.How useful really are Entity Beans?I have read conflicting reports about their benefits.Some praising them and the others saying that they are useless.I am kind of confused about their utility.Is there a "thumb rule kind of a thing"?For eg Entity Beans can be used only in certain situations?Pls help.
 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Krishnan,

At this time they probably don�t have much use and in a fair world they would probably never had. There are though several contexts where they might came handy but in my opinion, not without involving vendor specific solutions. As an example consider the read-only concurrency strategy that weblogic provide, which can implement very efficient caching strategies. Unfortunately by doing this, one will break the builds once run everywhere promise that is a fundamental j2ee feature.
The main problem with ejb is that the specifications are far of being even acceptable. I personally am still surprised that sun could get away with this for such a long time. Without going to deep into the matter you have to understand that poor container vendors tried their best to come up with good solutions that could still be compatible with the j2ee junk specs. This is the reason why these guys come up with so many vendor specific solutions, in order to make things work.
With regard for the entity ejbs they have a very bad reputation and one has to either provide a j2ee standard solution, which will mostly perform very poorly, or to employee vendor specific solutions and to come up with a non-compatible j2ee solution. The second approach has also the drawback that developers must know the container very well and why should they?
Regards.
 
KrishRads
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks a lot Valentene.But are they not recommended when you read data which doesn't change.For eg when you use Read-only Entity Beans for Caching.Or is it there is too much overhead when using an Entity Bean for this purpose.

Thanks again.

Regards
Krishnan
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


But are they not recommended when you read data which doesn't change.For eg when you use Read-only Entity Beans for Caching.Or is it there is too much overhead when using an Entity Bean for this purpose.


They are actually recommended for caching data that doesn�t change very often. As you already know the problem with caching is the stale data (when the data in db changes and gets out of sync with the cache), but with this strategy weblogic allow refreshing the cache after a specified interval of time. It also allows invalidating the cache programmatically. As for performances or overhead, nothing like this it works very well and the container is capable of caching a large number of ejbs without affecting the performances.
The huge drawback of this approach is that this is a weblogic specific solution and it won�t work if the beans get deploy on JBoss for example. Another problem is that this solution is neither intuitive nor standard and requires weblogic experience. But again it works and performs really well, it is also very easy to implement or maintain and it really makes me sometimes to just forget about the j2ee crap and care more about what the container can do for me. This is actually the point I try to make with entity ejbs: use only standard j2ee feature/patterns/recommendations and you are very closed to failure; screw them, learn more about your container capabilities and you might be very successful. Finally I just want to remind you that j2ee made a lot of great promises a while ago after releasing ejb 1, they made even greater promises after releasing ejb 2, but at the end of the day you might notice that they are kind of forgetful ...
Regards.
 
reply
    Bookmark Topic Watch Topic
  • New Topic