• 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

�Session Beans vs Entity Beans�

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
First of all, sorry bout my english.
I am developing a J2EE/EJB Web Application using SessionFacade pattern.
The problem is that most of developers advice me not to use Entity Beans if I have lots of users, so I decided to use Session Stateless Beans.
if so...
Which are the advantages of using EJB instead of usual java Beans w/ JDBC Api??? Because I lost the (I think) main advantage what is transaction management...
Does session facade pattern makes sense then?
Where must I make DB calls? in session beans or must I develop some clases for the DB access to be called from SessionBeans?
 
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

First of all, sorry bout my english.


Don't worry, mine is not better


The problem is that most of developers advice me not to use Entity Beans if I have lots of users, so I decided to use Session Stateless Beans.


I don't think you could obtain an answer about that.
Some say "Never use Entity beans", other are fans...


Which are the advantages of using EJB instead of usual java Beans w/ JDBC Api??? Because I lost the (I think) main advantage what is transaction management...


1- OO design
2- The EJB container can manage transaction, isolation level, and some security rules for you
3- The container's programmers are supposed to be better than you are. So relying on container is a safer solution.


Does session facade pattern makes sense then?


No, session facades are for Entity beans


Where must I make DB calls? in session beans or must I develop some clases for the DB access to be called from SessionBeans?


You develop classes called DAO (Data Access Object).
EJB calls DAO and DAO contains the code for data access

by the way, take a look at the Naming policy before a sheriff catches you !!
HTH.

[ January 29, 2002: Message edited by: Bill Bailey ]
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One thing:


Does session facade pattern makes sense then?
-----------------------
No, session facades are for Entity beans


Sorry, but the Session Facade Pattern works regardless of whether or nor you use Entity Beans. The idea works just as well with plain old Java classes doing the JDBC work as it does with Entity beans.
Kyle

 
jose maria
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, and thanks all for your answers.
Kyle, nice documents!
So, using Facade Pattern I will have:
Client [in my app. a servlet] that ask for data to a Session Stateful EJB [facade].One per use case.
Facade calls Stateless session beans.
And these stateless EJB have DAO for DB calls.
Then the facade returns a serializable object to the servlet that uses it with jsp to generate the view.
Is it right?
So, must I make one DAO per DB query?
Is it better to create the "Java serializable objects" that facade forwards to the servlet inside the DAO itself or return the resultset to the session bean which will create the object.
Thanks again.
[ January 30, 2002: Message edited by: cardiac0 ]
 
Kyle Brown
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, my preference is to have the DAO make the return objects (the Serializable ones) rather than just returning a ResultSet, but that's personal preference. Your mileage may differ.
When I do so that usually ends up with one DAO per return class type -- which may end up being several related queries.
Kyle
[ January 30, 2002: Message edited by: Kyle Brown ]
 
mister krabs
Posts: 13974
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
cardiac,
Please note that JavaRanch has a naming standard that you must abide by to post here. You must use your real first name - space - your real last name as your display name.
 
JeanLouis Marechaux
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Sorry, but the Session Facade Pattern works regardless of whether or nor you use Entity Beans. The idea works just as well with plain old Java classes doing the JDBC work as it does with Entity beans.



Yes, I know Sun has changed its mind between 2000 and 2001.
In 2000, a facade where ONLY for Entity objects.
Then from 2001, a facade can be for any kind of object.
So you're right Kyle. I was myself too EJB-centric when I answered the question.


for data to a Session Stateful EJB [facade].One per use case.


I don't think you sould have 1 session facade per use case. This will result in too many SF objects.
A better approach should be to "group " related use cases in 1 SF.
For instance createOrder, modifyOrder, deleteOrder could be in 1 SF called manageOrder.
(so the SF aggregate many use cases)
 
jose maria
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But I still hav one IMPORTANT question...

How can I save the state of every EJB...Now they are not entityEJB, they are Stateless...
How do you save them??? How do you manage this problem...
 
JeanLouis Marechaux
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can have Stateful session beans.
 
Ranch Hand
Posts: 977
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by jose maria:
But I still hav one IMPORTANT question...

How can I save the state of every EJB...Now they are not entityEJB, they are Stateless...
How do you save them??? How do you manage this problem...



Hi,
If you don�t wanna use Stateful session bean as Bill mentioned you�ll have to keep the state on client side and pass it as parameters for your stateless session bean, be aware that this approach should not be used for big ammounts of data(you�ll use the network to pass the state), you may also use http session and keep the client state on the web server.
 
jose maria
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I still don't understand which are the advantages of using EJB instead of usual java Beans w/ JDBC Api...
If Entity Beans are not desirable and my system does not need distributing objects...why use stateless session beans instead of servlets-javaBeans-jsp???
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic