Stateful Session Bean Safety


EJB design: Stateful Session Bean Safety

  1. Stateful Session Bean Safety (3 messages)

    I am designing an application that is using a SFSB to track the state of an interaction with the client, which happens to be a web client.

    The interaction proceeds: methodA() followed by methodB(), and methodC(). Each method accesses/mutates the state of the SFSB. I should mention that user interaction is required between methods A, B, and C.

    Here is my question: If two browsers from the same client access the servlet, it will spawn two threads, which may end up trying to access the same SFSB, whose reference is in the HttpSession.

    The petstore uses a synchronized proxy to prevent these two threads from accessing the same method. But what if thread1 is accessing methodA(), and thread2 is accessing methodB()? Synchronizing individual methods won't prevent this.

    What is the best way to safeguard a sequence of method calls in a SFSB? I am leaning towards Transactions, but some detail on your experiences are appreciated.

    Thank You,

    Threaded Messages (3)

  2. Stateful Session Bean Safety[ Go to top ]

    A synchronized method aquires a lock on the instance it is a member of. Only a single synchronized method (or synchronized block for that matter) can own a lock at a given time. So if all your methods are synchronized, they will be mutually exclusive. E.g, while a call to A is in process, calls to A, B and C will block. Isn't that what you want?

  3. Stateful Session Bean Safety[ Go to top ]

    Hi Gal --

    Thanks for the reply. You are correct-- the synchronization will prevent concurrent accesses no matter what the method. The more I think about it... I think I may be approaching the problem wrong.

    I'd like to see this:

    thread 1 calls SFSB.methodA()
    thread 1 calls SFSB.methodB()
    thread 1 calls SFSB.methodC()

    and thread 2 can't call any method while this sequence is in motion.

    of course this *can* happen, even with synchronization:

    thread 1 calls SFSB.methodA()
    thread 2 calls SFSB.methodC()
    thread 1 calls SFSB.methodB()
    thread 2 calls SFSB.methodB()
    thread 1 calls SFSB.methodC()

    There really isn't a problem for application clients, which can create, hold, and protect an SFSB from unwanted callers. The web client is what gives me headaches. Since more than one thread can access the HttpSession, there's no "automatic" way to keep a second thread from calling a method on the SFSB (provided no one else is using it).

    I think the correct approach may be to keep the second thread from getting a hold of the SFSB in the first place, or at least code the SFSB so it is "thread agnostic" -- methods can be called in any order, by any client.

    Your input is appreciated!

    Thanks Again,

  4. Stateful Session Bean Safety[ Go to top ]

    It seems to be a rather bad practice to put stateful refs into HttpSession and I do not why Sun still didn't realize it.
    Anyway, if you use synchronization you will sacrifice perfomance. I am currently using the following pattern that allows to manage session-specific information in business logic tier:
    1. I have a separate copy of SFSB for each client that is created during login sequence. There is also a class binded to JNDI that represents HashMap. Keys are session keys, values are handles to SFSB associated with this session key.
    2. I have my own presentation framework (that is decreases the development speed in many many times comparing to Struts, WAF and other frameworks). It's fully XML configurable and effectively uses Java reflection. I redirect ALL HTTP calls to central servlet and it decides which method and of which session facade to call based on the arguments provided. The result returned by session facade represents JDOM object, that is either transformed to XSLT or contains "forward" link to the next screen. Framework passes session key to facade every time it knows that the method to be called is actively using user-specific data. It's method's task to retreive specific SFSB and modify or use data in it.
    3. I also use servlet filtering for user authentication purposes, so it helps me to increase perfomance automatically banning wrong callers (of course, everything is double checked in the business layer). That's the only thing where I use servlet HTTPSessions.
    This kind of architecture is already tested on several large production systems.
    That's my 2c