Monson-Haefel's book says when describing stateless session beans that :-
"many EJBObjects can use just a few instances of a stateless session bean"
"A stateless session bean does not maintain conversational state relative to the EJBObject it is servicing, so it can be swapped freely between EJBObjects"

Does this mean the following are true ???? :-
1. Multiple EJBObjects can be associated with a single instance of a stateless session bean.
2. Each client is associated with it's own EJBObject.
Further, does the same or similar apply to Stateful session beans and Entity beans ????
Thanks very much in advance.
 

This is a EJB newcomer's reply.

Your assumption on #1 is valid but not #2.

Both #1, #2 are not applicable to StateFul SessionBeans and EntityBeans.

A stateless session bean [SLSB] is associated with the client only for the duration of the Method call. Once the call is thru, the SLSB is disassociated with the client.
It is so since it does not have any properties to retain that info.

- suggest more reading
- hope this helps

Further to query #2 :-
For the duration of the method call, does the client use one particuler EJBObject (that no other client will use at the same time) for access to the SLSB ??
the association between the client and EJBObject, and EJBObject and SLSB, being dropped after the method has executed ???

Thanks in advance

How is threading done for beans in a container?

Are the beans threaded for muliple requests? If every request to bean over the wire is going to hold a physical instance to logical EJBObject can to client side EJB objects have muliple (different clients) reference of same physcial instance and also issue concurrent requests?

Question crossed my mind, probably specs says something on this.

- Madhu

This is a EJB newcomer's reply.

Your assumption on #1 is valid but not #2.

Both #1, #2 are not applicable to StateFul SessionBeans and EntityBeans.

A stateless session bean [SLSB] is associated with the client only for the duration of the Method call. Once the call is thru, the SLSB is disassociated with the client.
It is so since it does not have any properties to retain that info.

- suggest more reading
- hope this helps

hi,
I am not clear about , stateless bean having "pool" of objects to be used by multiple clients.when those instances will be created or who will generate them.
Is this pool specific to ejb container or any vendor container.
thanks advance,

An EJBObject is a logical idea. It is the logical instance that a client is using. The container may use one or several physical bean instances to represent the one logical EJBObject the client is bound to.

So in a stateless session bean, when I find the object, I am coupled to a single logical EJBObject. Every method call however might be serviced by a different physical instance.

In a stateful session bean, as long as no passivation occurs, the EJBObject remains assocated with the same physcial instance. But once passivation/activation occurs, a new physical instance is associated with the logical EJBObject.

In entity beans it depends on the container but the same can be true. For one row, say id = 100, there can be one or more physcial instances that represent the single EJBObject. The differenc ehere is the EJBObject is associated with the persistant data not the client. In other words, two clients can share access to one EJBObject.

help?

Dave Wolf
Internet Applications Division
Sybase

Great help, thank you.

My question is if a EJBObject can handle multiple clients then what happens when ejbActivate() is called on the bean.

For example........
 
client 1 === c1 is calling bean A (instance a1) through EJBObject (E1).
 
a1 is passivated.
 
now E1 is serving client c2 with a2.....
 
a2 is passivates
 
now E1 is serving client c3 with a3.....
 
client c1 calls a method on E1 again.......(because it already had reference to that EJBObject) how does container know which bean instance to activate which was serving that client before. I know bean instance to be use this time can be different.....but how does container know that this client's state was passivated,,,,and how does container activate that client's state.....Does cotainer or EJBObject stores clients state and reference to their passivated data......???????

Actually Stateless session beans don't have states and also they can't be activated or passivated.(The title of the question says stateless) The bean instance will be in method ready pool after it served a client. For the stateful session beans only, the container stores the state in a temporary secondary storage, which will be retrieved and assigned to an instance when it needs an activation.

Actually the number of EJBObjects are container specific. It may create equal number of EJBObjects as clients, or only one. It all depends on container logic. But no matter how many EJBObjects are created, when the container activates, it has to give EJBContext(which contains server and client info), and states(stateful) to the bean instance.

-Senthil.

Thanks Senthil.

Actually I meant was Stateful sorry for misunderstanding. After a bean has been passivated then can that EJBObject (which was serving to that particular client) serve any other client.

If yes then how what happens when first client class a method. How does cotainer decides which data to activate. As there may be more beans already passivated. I mean how container decides which data belong to which client (data mean state for that session bean which was passivated) because EJBObject is now serving another client.

And what will happen in case of Entity Bean..

Thanks in advance
Hardeep

Thanks Senthil.Actually I meant was Stateful sorry for misunderstanding. After a bean has been passivated then can that EJBObject (which was serving to that particular client) serve any other client.

Hardeep,
  Again, it depends on how the container is designed to implement. When you lookup home interface and invoke create method, the client will get the stub dynamically from the container. There will be a skeleton for your stub on the server side. If a bean instance is disassociated with an EJBObject, the container will not disassociate the connection between the stub and skeleton. And also from the client side you need to keep the reference.(Handle will be used to store the connection in secondary storage). When you make a call from the client, the skeleton will understand from which stub the method invocation is initiated.

And also I think, when we invoke a method call, in addition to the method call, there are other contexts are also propagated like, SecurityContext, TransactionContext...

Thanks,
Senthil.

Thanks That really Helped.

In case of Entity beans an EJBOBject can reffer to multiple instance ot the same bean. And so it can serve different clients at the same time (How depends on container).What will happen in case of Entity beans activation/passivaton following the same assumption as in previous question..