Stateful/Stateless combination

Discussions

EJB design: Stateful/Stateless combination

  1. Stateful/Stateless combination (3 messages)

    Hi. Im in the process of designing a small card game(2-4 concurrent players), and I need to keep the state stored somewhere. I was thinking about putting most of the functionality together with state in a stateful session bean, but that doesnt scale very well. Another option is to have the state stored on the client side and use stateless session beans, but then I have to pass state data on every method call. I was thinking of another solution, using small light-weight stateful session beans to hold the state information, and link them to stateless session beans who do the hard work(with local interfaces). Is this a good solution which will scale well? How many bytes of memory do you think a SFSB with a couple of strings or integers + a reference to a SLSB will take? Thank you.

    Threaded Messages (3)

  2. Stateful/Stateless combination[ Go to top ]

    Question:

    Does the state apply only to one player or to the game as a whole (and therefore needs to be shared between players)?

    SFSBs only hold state for one client so won't work for shared state. The best option for shared state IMHO is a DB. You could even consider this for single client state as well as it means games can be put on hold and resumed at a later date.

    HTH
    Kit
  3. Stateful/Stateless combination[ Go to top ]

    The state applies to the game as a whole, and it will be stored in a DB. I think Im gonna use a SLSB only, and keep a "session id" in a local helper class on the client side, so the client doesnt have to pass the session id on every method call. This should make it easy for the client code, and scale well on the server side.
  4. Stateful/Stateless combination[ Go to top ]

    The state applies to the game as a whole, and it will be stored in a DB. I think Im gonna use a SLSB only, and keep a "session id" in a local helper class on the client side, so the client doesnt have to pass the session id on every method call. This should make it easy for the client code, and scale well on the server side.

    Sounds like a plan.

    Certainly the more server-side logic you can keep stateless and session-agnostic, the better the app will perform and scale.

    Good luck.
    Kit