'single-threaded'ness of ejbs

[Jim Clayson]

Hi,
I am led to believe that every ejb is single-threaded (Mastering EJB v2 by Ed Roman) although there may be multiple entity bean instances in the ready state which represent the same underlying data - for example one record in a db can be represented by more than a single entity bean instance in the ready state.
Now I would like to know what exactly does 'single-threaded' in this context mean?
I find that, often, the terms 'ejb', 'bean', and 'instance' are used interchangeably in your average techies vocab' when describing the goings on in an ejb environment i.e. many people use 'bean' when actually they mean 'bean instance'.
Does 'single-threaded' mean that for each entity bean instance a single thread will execute or does it mean that for each entity bean definition there is a single thread of execution? (And I'm assuming we are talking about a single processor environment here.I don't even know if ejb can run off multiprocessor architectured hw so it might not even come into it.)
Any help much appreciated.

[Jun Hong]

I think session beans are single threaded. We have stateful session bean which is specific to each client. So it should be accessed by one client at a time. In fact, a stateful bean is access by the same client all the time. A stateless bean is also used by one client at a time.
Entity bean are shared between clients. It is definitely multithreaded. The multithreading is controled by the container.

[Deepak Kumar]

Actually i dont think there is any form of multithreading in Entity beans or session beans ??
According to Ed Roman in his book "Mastering EJB2" he clearly says that a same instance of entity bean cannot be multithreaded as it is difficult to control the transaction.
So he has suggested the solution "Having a single instance serve all the clients". This will degrade the performance as it is sequential processing.
Alternatively we can allow the container to create multiple instances for the same bean and
Control the transaction by setting the isolation levels and transaction attribute.So the processing is concurrent rather than sequential.
and this is the method implemented in all servers
The above is the explanation given by Ed Roman

[Marcos Maia]

Hi,
Multiple clients can access an entity object concurrently. The container in which the entity bean is
deployed properly synchronizes access to the entity object’s state using transactions.
So EJBObjects are multi threaded and not ejb instances that are associated with a client(one thread of EJBObject proxy) during a method call.

[Jim Clayson]

Hi,
I have one session facade routing requests from a servlet to a CMP entity bean. The entity bean selects the least hit record and hands out the contents of an image-location field in that record and increments a counter field in the same record. This involves executing a finder, calling the counter field's getter and setter.
What I would like is for those three calls to be treated atomically and for that transaction to be properly isolated.
So, what you are saying is my container has assigned multiple entity bean instances(each of which represents the same db row and a different client request) to a single EJBObject. And the container is doing the synchronizing of access to the db record based on the level of isolation defined by its tools. Is this correct?
All I should have to do is to provide an appropriate level of isolation (and perhaps choose optimistic or pessimistic locking once I'm happy with my performance-to-data-integrity-preservation tradeoff). Is this correct?
As far as I can tell, the isolation level I want is REPEATABLE_READ or SERIALIZABLE. If I understand correctly, one of these would give me a high degree of data integrity but might impact severely on performance. Is this correct?
Any help is much appreciated.
Jim

[Kevin Yip]

Even though multiple clients can share the same session EJB remote reference, only a single thread may access the EJB at any given time. If multiple threads try to access the same client context, an exception will be generated.
For entity bean, each client has its own instance of the EJB class in the container and is not multi-threaded. Whether the EJB Object is multi-threaded or not depends on the vendor implementation.

[Tao Liu]

So, does it mean by that the stateless session doesn't have to be thread-safe?
"If multiple threads try to access the same client context, an exception will be generated." Could you please tell me what type of exception will be thrown?
Thanks a lot,
tao

[Kalpesh Soni]

lets say I have 5 instance of entity beans which represent same row in db
now how exactly do i use transaction attributes and isolation levels to ensure no concurrency problems
I use weblogic 7.1