I.e. a session bean performing an important and complex banking operation, then how can container guarantee the integrality of the key operation when more than one client access the same session bean? I think probably all concurrency control problem can boil down to a problem of entity bean, for session bean means business logic which has no need to worry about concurrency problem unless entity bean appears. Transaction may be a possible solution.

By using Transactions and defining the Isolation level you can achieve the desired safety.

Thanks for your reply.However,I'm not quite clear about the expense of Transaction.Performance is the key design issue in my project.

I think, there is no way to get win win in transaction and performance.

Regards,
Wallace

"Ejb container provides scurity by default.If a client is accessing an instance
it locks it untill it completes utilization,by passivating or removing.
By definiing isolation it can provide this.Two of the best isolation levels are TRANSACTION_READ_UNCOMMITED,TRANSACTION_SERIALIZABLE "

As per the spec, no two threads will ever access the same EJB bean instance at the same time (neither session, nor entity).

This removes the risk of threading-unsafe code in an EJB.

So, if you write a Session EJB, no two threads will ever be executing code in the same instance of the bean.

You are right.But what frighten me is not the fact that two threads will access the same EJB bean instance.In fact,I mean two client threads access two instances of the same EJB bean.

When you have multiple instances of the same entity bean, the concurrency is similar to ordinary Java class. Only, ejb provide deployment descriptor. You need to specify the suitable transaction attributes.

What is your problem in that scenario?