The EJB spec says that "the container serializes calls to each session bean instance" (this is 4.3.12 of the EJB 3.0 spec preview, but the EJB 2.1 spec has identical requirements).

A couple of paragraphs later it says that "clients are not allowed to make concurrent calls to a stateful session object".

Now, I don't understand how can a client make concurrent calls if the container serializes them.
Probably I'm missing something big here since I tried to find answers in several discussion forums with no luck.

Thanks!

Alex

I guess, you mixing up serialization with synchronization.

the container serializes calls to each session bean instance

Serialization means that every method call is converted into a stream (see it as a string), which has enough info to identify the bean, its method to call and parameters' values

clients are not allowed to make concurrent calls to a stateful session object

client is not allowed to make a second call to the same instance of the statefull bean (use the same EJB stub) while the bean is still busy wiht processing the first call.

Does it help?
Viktor

I understand this in the following way.

Serialization means that container ensures that no other invokations are made on the instance while the instance is already handling an invokation.

In the case of statless session beans this is usually hanlded by routing concurrent requests to different bean instances. In the case of stateful session beans this is handled by throwing exception.

To me, this seems to be reasonable because concurrent calls to a stateful EJB lead to unpredictable results in terms of the application state. Usually, this is a sign of a programming or design error.

Hope, this helps.

Your consideration did somewhat help me.
I think the main point that the spec wanted to stress is that the container guarantees that each session bean instance receives one method call at a time. The way it stressed it, though, is ambiguous.

As far as I understand, the guarantee I mentioned above can be put in practice with the following techniques:
1. if the bean is a SLSB, the container tries to send the method call to another instance (I suppose by searching in the container among the SLSBs which are ready)
2. if the bean is a SLSB and it is not possible to delegate the call to another instance (too many instances are running in the container), then the method call is serialized to one of the executing bean instances; it is important not to confuse here method serialization with object serialization (*)
3. if the bean is a SFSB, the container returns an exception to the client

This makes sense. I suppose the reason why I didn't get it at first was because the spec was associating method serialization to the concept of session bean, while what it meant was associating it with the concept of SLSB.
The container never serialize methods on SFSB as the spec seems to imply.

Can anyone confirms that this is the intended semantics?

Thanks!

(*)
This is the usual definition of method serialization:
Time 1: the SFSB receives a call
Time 2: the SFSB is still executing the call 1 and the same client or another client sends another call (call 2). The container puts the second call on wait until call 1 ends. When call 1 ends, the container unblocks call 2 and the SFSB receives it.