• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

EJB basic Questions

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
I am new to EJB. When Iam trying to explore ,
Few basic questions are really troubling me in EJB. I would like to know whether my thinking is right .

1) For Statelss session beans , ejbCreate() will be called only once because of pooling.

2) For Statefull session beans ejbCreate() method will be called everytime as per request because we
cant pool.

3)Whether Stateless session beans can be accessed by multiple cleints.

4) Why multiple client access is not supported in Session beans, when session beans support transactions.
5)Whether the only main difference between Statefull session bean and Entity bean is the multiple client access support.

It will be thankfull to me if you people provide some light on above things with specific examples.

Thanks

Krishna
 
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1) For Statelss session beans , ejbCreate() will be called only once because of pooling.

correct, once for each bean, as for stateful session beans. The point is that the container will most probably never call remove(), therefore he don't need to create new beans.


2) For Statefull session beans ejbCreate() method will be called everytime as per request because we
cant pool.

wrong, during the session bean lifecycle ejbCreate() is called once. The container may or may not passivate the bean between different requests. A bean is assigned to exactly one client

3)Whether Stateless session beans can be accessed by multiple cleints.

yes, they can be accessed by multiple different clients, but not at the same time. The container guarantees to serialize the requests

4) Why multiple client access is not supported in Session beans, when session beans support transactions.

I never heard that. The only point I know is that one instance can't be accessed at the same time

5)Whether the only main difference between Statefull session bean and Entity bean is the multiple client access support.

[B] no, see above. The main difference is that a Stateful session bean has a conversational state. This has different impacts:

- Only one client can have a conversation with the same bean instance
- multiple client calls can be made in one transaction (BMT only)
- clustering is more difficult (session synchronization)
...

Severin
 
rajenag neelam
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thankx for reply

1)I want to know whether multiple cleint access is supported in Statefull Session beans.
2) I read in a book that for Stateless session bean there will be pool,
and for Statefull session bean there will be cache.
And For entity bean there will be both pool and cache.

Please explain me How they are realted with Lifecycles and clients of that beans.
 
Ranch Hand
Posts: 241
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by rajenag neelam:


1)I want to know whether multiple cleint access is supported in Statefull Session beans.



As Severin said, it�s not allowed that the same instance of a session bean (neither stateful or stateless) can be accessed in the same time per 2 differente clients. If it happens the second client will receve a RemoteException (or EJBException if the client is local).

Originally posted by rajenag neelam:

2) I read in a book that for Stateless session bean there will be pool,
and for Statefull session bean there will be cache.
And For entity bean there will be both pool and cache.

Please explain me How they are realted with Lifecycles and clients of that beans.



The stateful session bean will not be pooled because its lifecycle dependes of the client. When the client calls create on the component interface (EJBObject or EJBLocalObject) the container calls the bean�s default contruct followed by the callback setSessionContext and ejbCreate. The bean�s states will be cached (storaged in memory) while the bean is activated. When the client calls remove on the component interface, the container will call the callbacks ejbRemove and the bean will be destroyed. PUFT !!! There�s no need for pools.

The stateless session bean is little different. The container calls the callbacks when IT WANTS to. The client doesn�t intefere in this moment.
The container create the beans and put then in a pool (one pool for wich type of bean, i.e: CostumerStatelessSessionBean, ProductStatelessSessionBean). When the client calls a business method, the contained catch one bean from the pool, execute the its business method and then puts the bean back to the pool.

For entity beans, the container creates a bunch of beans and put the in a pool (one pool per wich type of bean). The client can do many things with an entity bean(he can call home business method, finders, selects, business methods) and the container will comport accords of client�s request.
See HFE pg. 320 for entity bean instance lifeclycle.
As entity beans represents entitys (rows in a database) the container can cash it state for enhance performace because accesses DB every time that an bean is requisited costs a lot.

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

Originally posted by Severin St�ckli:

[B] no, see above. The main difference is that a Stateful session bean has a conversational state. This has different impacts:

- Only one client can have a conversation with the same bean instance
- multiple client calls can be made in one transaction (BMT only)
- clustering is more difficult (session synchronization)
...

Severin



I think that the main difference of session and entity beans is that a session bean represents a process like a credit card validation while entity beans represents entities stored in a DB, like a costumer or product.

Regards,
 
Severin Stoeckli
Ranch Hand
Posts: 62
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
think that the main difference of session and entity beans is that a session bean represents a process like a credit card validation while entity beans represents entities stored in a DB, like a costumer or product.

oh, yes, sorry, I described the main difference between stateful and stateless session bean. You're absolutely right, Vinicius



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

Originally posted by Vinicius Boson:


The stateful session bean will not be pooled because its lifecycle dependes of the client. When the client calls create on the component interface (EJBObject or EJBLocalObject) the container calls the bean�s default contruct followed by the callback setSessionContext and ejbCreate. The bean�s states will be cached (storaged in memory) while the bean is activated. When the client calls remove on the component interface, the container will call the callbacks ejbRemove and the bean will be destroyed. PUFT !!! There�s no need for pools.



I think here the EJB Container vendor could provide a pooling mechanism for stateful session beans also. What matters for the client's point of view is that between method invocations, the bean it's talking to maintains the same conversation state. But the 'physical' bean instance that will actually 'dress' with the client's state may actually vary, or this is what was being discussed on this forum few days ago...A way of realizing pooling for stateful session beans would be to serialize/deserialize client's state during passivation and put the bean's instance back to the pool. When the client invokes a business method, the container could take out a bean of that type from the pool, assign to it the client's state when invoking ejbActivate() and as far as the client is concerned, it was talking exactly with the same bean as before. This approach could be efficient in an e-shop site with thousands of clients doing shopping at the same time. It would save the container from having thousands of bean instances, if the pool would be smartly managed. At the end, serialization (or whatever is used for it) is done anyway when the container decides to passivate the bean.
 
rajenag neelam
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for all your replys.

I have got lot of information from that.
I would like to know,
Statefull Session beans can also access database as Entity beans and also can involve in transactions.
So still iam not sure whats the main difference.

In one article I read that main difference is in number of client access of a Bean.

Please throw me some light on this one.

Thankx
Krishna
 
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
IMHO, accessing data is different than representing data.
It is possible to design application without using Entity Beans. This is a very hot debate whether to user or not to use EJBs you can find interesting information on www.theserverside.com
One interesting article can be found here Don't Make me Eat the Elephant Again :)

I believe we are here to understand what EJB are so here is my understanding about Session and Entity Beans


Session Bean
�You think about verb
�Represent a process (MAY BE operating on data obtained from database)
�Executes on behalf of client.
�Although they can access and update data, the state of a session object is non-persistent and need not be written to the database
�A session bean typically executes on behalf of a single client and can not be shared among multiple clients

Entity Beans
�You think about nouns
�Represent something in persistence store (think about a row in database)
�State of EB must be written to database either by container (CMP) or by Bean provider (BMP)
�An entity bean can be accessed by multiple clients at a time (HFEJB page 99, Entity bean clients share the Home and may share the bean)

Basically, my understanding is that EB represent data, and SB act on that data (although SB also can access data using other techninques)

Hope it helps
 
rajenag neelam
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thankx for sharing ur knowledge.
I would like to know one thing .How Entity beans differ from Session beans

l came across to this answer every where. But iam not getting satisfactory answer.
Everwhere i found answer as Entity bean is persistent. and Session bean is not persistent.
But as session beans can also do persistent operations by involving in database and transaction operations.

And also i found Entity beans will operate on row, While Sessionn beans operate on data.
What this actually means,Anhow we are updating database by both of these beans.

Please share your knowledge regarding this.

Thankx
Krishna
 
You’ll find me in my office. I’ll probably be drinking. And reading this tiny ad.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic