Reputation: 11
I'm very new to EJB 3.1 and am trying to solve a server side problem; perhaps someone could offer some guidance.
I have a state machine that represents the shared state of multiple users in my application. I'm attempting to model this state machine as a Stateful Session Bean; since there are multiple users represented by this State Machine, I introduced a Singleton Session bean that is the actual Client of the StateMachine and all of the users end up being "Clients" to the Singleton bean. My problem arises when I want to lifecycle multiple StateMachines throughout the life of the Application.
I would like my Singleton bean (the "Manager") to handle client requests and distribute to the appropriate StateMachine - how would I access specific instances of that Stateful bean? To add further complexity, I'm trying to access these StateMachine beans remotely (if it were local, I'd just create instances of these things as members of the Manager).
Anyway, I hope this is clear. I feel like I'm missing some fundamental point of EJB design; y'all will tell me if that's the case.
Upvotes: 0
Views: 1431
Reputation: 9592
Singletons have been introduced in EJB 3.1 providing the ability to share state between multiple instances as described in A Sampling of EJB 3.1.
Singletons
A long-standing omission in the EJB API has been the ability to easily share state between multiple instances of an enterprise bean component or between multiple enterprise bean components in the application. By contrast, the Java EE web application programming model has always provided this type of capability through a ServletConfig object. In EJB 3.1, this omission has been addressed with the introduction of singleton beans, also known as singletons.
A singleton is a new kind of session bean that is guaranteed to be instantiated once for an application in a particular Java Virtual Machine (JVM)*. A singleton is defined using the @Singleton annotation, as shown in the following code example:
@Singleton public class PropertiesBean {
private Properties props; private int accessCount = 0; public String getProperty(String name) { ... } public int getAccessCount() { ... }
} Because it's just another flavor of session bean, a singleton can define the same local and remote client views as stateless and stateful beans. Clients access singletons in the same way as they access stateless and stateful beans, that is, through an EJB reference. For example, a client can access the above PropertiesBean singleton as follows:
@EJB private PropertiesBean propsBean;
...
String msg = propsBean.getProperty("hello.message"); Here, the container ensures that all invocations to all PropertiesBean references in the same JVM are serviced by the same instance of the PropertiesBean. By default, the container enforces the same threading guarantee as for other component types. Specifically, no more than one invocation is allowed to access a particular bean instance at any one time. For singletons, that means blocking any concurrent invocations. However, this is just the default concurrency behavior. There are additional concurrency options that allow more efficient concurrent access to the singleton instance.
Have a look at Java EE6 Events about how to send notifications using events.
Upvotes: 1