I've looked around and haven't found anything on this

I have a state machine for my application which, among other things" contain counters. these counters are updated fairly rapidly(once every second) depending on external messaging.
The state machine is contained in a statelses session bean.
The session bean reads the statemachine from the InitialContext and if it doesn't exist, creates it and rebinds it to the context.

Here's the weird part. A singelton utility class listens on a UDP port for XDR messages(corba like). On init of this singelton it looks up the statemachine session bean home and creates a bean instance. This bean instance is cached throughout the entire lifecycle of the singelton. Not the home, but the bean itself(seems weird but ok). Every time the singelton receives an xdr message it calls a method on the session bean to update the state machine.

The session bean then only uses its class member state machine and updates that, never touching the one bound in the context.

My problem is that sometimes I somehow end up with 2 statemachine session beans which has statemachines at different states. My listening singelton only updates its cached bean instance.

so a question is: If I changed it so my singelton created a bean instance every time, it would have to do a lookup on context and get the statemachine, update it and then rebind to the context when done. This seems pretty expensive. Id it?



Are there other approaches to statemachines considering they need to be updated fairly rapidly.

thanks

Hi,
I think you need to convert the session bean that contains your stete machine from stateless to statefull.
Best regards, Mircea

hmm... ok, But this stateful bean would be active for months(years hopefully).
Basically for the lifetime of the singelton. Is this an ok approach?
Any lifecycle timeouts connected with it per ejb spec? or would this be vendor specific?

thanks,
Henrik

Hi,
If you need the life span of the state machine is months/years this changes the prblem. If the statefull session bean is processing requests often enough the container won't get the chance to pasivate it. However, if the bean is passivated and there is no further call in a timeout period, the container will destroy the bean. The timeout configurations are vendor specific. In this second case, when you need to maintain the state for a long period of time you should proviode mechanisms for saving the state in some persistent storage, like a database, and reconstructing the state from the database.
Best regards, Mircea

good advice, thanks.

One more question.
Since my listening singelton which uses the bean is multithreaded, it can receive and process multiple request concurrently, thus I get into accessing my session bean concurrently. This would be a violation of of the spec wouldn't it?

Assuming so, I would have to handle synchronization in my listening singelton to force only one request processed at a time. correct or not?

Also, if other component of the system wish to check the status of the
state machine, how can they access the "correct" stateful bean?
Only the currently active bean would have the correct state. Even if I persisted
the statemachine at regular intervals somehow the data would be stale very fast.

I was looking into having the statemachine as a singelton, however that breaks fast in the context of multiple classloaders and JVMs. So no luck there.

I can't believe I'm the only one that has had this problem, but I can't find any other similar discussions.
Someone must have solved this problem before me :)