Support concurrency on Stateful EJBs

[glassfishrobot]

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.

Affected Versions

[3.2]

[glassfishrobot]

Reported by exabrial

[glassfishrobot]

dblevins said: 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.

[glassfishrobot]

pedrokowalski said: 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 ?

[glassfishrobot]

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

[glassfishrobot]

mvatkina said: 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.

@Stateful
@LocalBean
@TransactionManagement(value=TransactionManagementType.BEAN)
public class SFSB implements Serializable {

    @Inject UserTransaction ut;

    public void beginUT() throws Exception{
        ut.begin();
    }

    public void commitUT() throws Exception{
        ut.commit();
    }
}

[glassfishrobot]

Was assigned to mvatkina

[glassfishrobot]

This issue was imported from java.net JIRA EJB_SPEC-24