[EJB_SPEC-24] Support concurrency on Stateful EJBs Created: 10/Oct/11  Updated: 07/May/13

Status: Open
Project: ejb-spec
Component/s: None
Affects Version/s: 3.2
Fix Version/s: Future version

Type: New Feature Priority: Major
Reporter: exabrial Assignee: marina vatkina
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


By default, JEE synchronizes access to a stateful EJB to only allow a single thread at any given time.

EJB 3.1 brought about the @Singleton annotation, along with two simple annotations: @Lock(READ) and @Lock(Write). These two anntotations should be ported to Stateful EJBs. Since the whole world is going concurrent, these controls will be completely necessary in the future. This would be extremely useful in Domain Driven Design.

The usefulness of this suggestion is greatly enhanced if there was a way to grab a handle to a Stateful EJB3. I'm putting the latter suggestion in another JIRA ticket.

Comment by dblevins [ 11/Oct/11 ]

This is also a feature I'd like to see if we can figure out how to add. It was discussed some in EJB 3.1 – don't recall if that was email or concall.

The "gotcha" that stopped it from being seriously discussed is what to do about the existing transaction related locking semantics of stateful session beans; i.e. a stateful session bean in a transaction cannot be invoked from outside that transaction.

There are a few ways to come down on that. One might be to reevaluate that requirement; singletons can hold as much if not more state, yet have no such restriction. Another might be to find a way for the two to co-exist; does it make sense to have both semantics and if so how? As well the concept of removing a stateful session bean that threw a business exception is a show stopper – that equates to lock upgrading as any method could become a "write" method (deleting the bean itself is definitely a write operation).

Definitely see the above as a "go" sign and not a "stop" sign. If we can figure it out, we can probably do it

Sometimes I wonder if we shouldn't just make @ManagedBean be declarable as a form of Session Bean. Basically a clean-slate Stateful. A plain old java bean with user-controlled lifecycle (on the surface that's what stateful beans are) should have no issues supporting @Lock. It's only when factoring in transaction exclusivity, transaction synchronization (session synchronization), passivation and similar concepts that a simple @Lock usage on a plain proxied object becomes hard.

Comment by Piotr Nowicki [ 07/Nov/11 ]

I would gladly see this feature in the future specification release.

David, by mentioning the transaction-related constraints, are you referring to the requirement that says that SFSB must be a part of at most one transaction? If so, than I would definitely opt for constraint re-evaluation rather than preservation.

If it comes to the Locking semantics and removal of the SFSB - would it be possible to move the responsibility to the developer? If he wants to have a concurrent access to the SFSB - Lock(READ) - than he must be prepared that in case any of the client requests throws an appropriate exception (thus resulting in transition to the 'does not exist' state) than all requests will fail.
I think it's just a matter of informing the user about possible outcome of such concurrent configuration.

EDIT: David, isn't your suggestion about POJO and @Lock annotation somewhat connected with Reza's case: http://java.net/jira/browse/EJB_SPEC-4 ?

Comment by marina vatkina [ 29/Jan/13 ]

If Websockets start using SFSBs extensively and need a fine grained concurrency support, we'll look at adding it.

Comment by marina vatkina [ 07/May/13 ]

BMT SFSB concurrent access needs to be clarified as well - in the code below the 2nd call to beginUT() will fail because the bean is already associated with a transaction.

public class SFSB implements Serializable {

    @Inject UserTransaction ut;

    public void beginUT() throws Exception{

    public void commitUT() throws Exception{
Generated at Mon Apr 27 00:24:16 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.