• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Comparing Session and Entity Beans

 
Madhu Juneja
Ranch Hand
Posts: 176
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Arch objective :
Comparing Session and Entity Beans
Although both session and entity beans run in an EJB container, they are quite different. The following table contrasts session and entity beans:
Purpose

SB : Performs a task for a client.
EB : Represents a business entity object that exists in persistent storage.
Shared Access
SB : May have one client.
EB : May be shared by multiple clients.
Persistence
SB : Not persistent. When the client terminates its session bean is no longer available.
EB : Persistent. Even when the EJB container terminates, the entity state remains in a database.
 
John Wetherbie
Rancher
Posts: 1449
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You may want to compare and contrast stateless session beans and stateful session beans.
John
 
Madhu Juneja
Ranch Hand
Posts: 176
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Comparison between Stateless and Stateful :
Functionality
Stateless : Execute a request and return a result without saving conversational state.
Stateful : Performs tasks for a client and maintain state on behalf of client.
Shared Access:
Stateless : Container may share these beans across difference Clients (after method completion)
Stateful : Always specific to 1 client.
Garbage Collection
Stateless : When remove() in invoked, they are not garbage collected (often) and are retained to service other clients due to their nature of not maintaining state.
Stateful : When remove is invoked they are GC'ed.
Resource Management
Stateless : The container maintains less Stateless beans in pool as it can reuse the same bean after method completion.
Stateful : The container has to maintain more of these (more than Stateless) in Pool.

Performance
Stateless : High performanent as they do not have to perform Loading and Storing the conversational state.
Stateful : Comparing to Stateless, they are low performanent.
Please add / correct the above. Thanks.
 
Giri Prasad
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Madhu
Shared Access
SB : May have one client.
EB : May be shared by multiple clients.
I am confused reading it. Here by Bean do u mean a Bean instance or the bean data(intespective of howmany instances are there in memory).
Why is that Session Bean has single client when a stateless session bean is not client dependent and Entity bean is shared???
I read from Ed Roman book that "Each bean (entity or session) can service only one client at a time (single threaded)"
Am I going wrong somewhere?
Thanks
 
Avijeet Dash
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you have heard about Proxy Pattern and Flyweight Pattern, these 2 patterns are used the way the beans are handled.
every client has a unique remoteObject instance, which works as a proxy to the state-less session bean or entity bean. and because the bean instances can be reused across clients they are pooled as flyweight objects.
 
Madhu Juneja
Ranch Hand
Posts: 176
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What you quote is right. With both Session and Entity Beans, all bean instances are single-threaded.
By saying the "Entity Bean : May be shared by multiple clients :
As entity beans instances are a view into the database. They represent the data in the database. When more client request the same data, the container instantiates more than one instance of the same record. This means multiple beans represent the same data. This is what I meant.
Answering another question, Stateful session bean is specific to one client. Stateful Session bean request one client and then when the remove() method, the object is GC'ed. But in the case of Stateless, it requests one client and then when the remove() is invoked, goes back to the pool to wait to request another client.
Hope it is clear.
 
Ian J
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Madhu, thanks for the informative compare and contrast info. You write: " SB : Not persistent. When the client terminates its session bean is no longer available." I think we can obtain and serialize the handle to a secondary storage and retrieve the hand back sometime later. Session bean instance will be available as long as its time_to_live does not exceed. Does it mean the session bean would be available after the client terminate?
 
John Wetherbie
Rancher
Posts: 1449
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ian,
Please review the Java Ranch naming policy and consider re-registering.
Thanks,
John
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic