Discussions

EJB programming & troubleshooting: How to determine if EJB client is disconnected?

  1. 1. I have client calling EJBs remotely.

    2. The client performs "login"
    by providing credentials into InitialContext
    and performing first lookup and first
    EJB method call e.g. "loginMe()".

    3. After that all method calls are made
    in the context of specified in credentials
    user Id (this is according to EJB standard)

    4. I have also requirement saying that two
    clients must not be able to connect server
    in the same time

    Question: I'm searching for the methodics
    how to satisfy the requirement (4). What
    would you recommend to do?

    One of the first ideas coming to my mind is
    to write a record into database with "loggged in"
    mark inside the "loginMe()" method and check the
    record to determine if some client is already
    logged in (in this case the "loginMe()" will
    throw a kind of LoginException). When client
    logs off it will call a "logoffMe()" method
    which update the record with "logged off"
    mark.
    But what to do if client application crashes?
    Can I determine this somehow on the server side?

    Probably somebody have more elegant solutions
    for my issues.

    Threaded Messages (4)

  2. Correction[ Go to top ]

    I've made a mistake in the 4th paragraph.
    It should contain also "with the same user id" at the end.

    So, it must be:

    4. I have also requirement saying that two
    clients must not be able to connect server
    in the same time with the same user id
  3. Write your own.[ Go to top ]

    You could use a statefulSession bean as the facade with Command pattern. Pretty nasty but it would work.

    A more elegant solution is to implement a watchdog via JMS, so the client sticks a message on a queue. Server side MDB inserts the time into the database. Seperate timer process on the server side deletes all rows in the DB that haven't been updated for X minutes. As long as the client sends a message less than X minutes it should all hang together.

    The simple answer is you can't. By definition, if you are using a stateless SSB the server has no concept of a client other than during the execution of a single method.
  4. Re: Write Your Own[ Go to top ]

    Thanks Colin. You confirmed my opinion.

    It's really missing concept that could be in the EJB standard. Solution with JMS is ok. But it can not ensure that client which was unable to send JMS in the specified time can not awake and try to call any other ejb method. This can happen when link with serever disappears for some time and by this time another client with the same user id can be logged in but previous client must not be allowed to make any new call, his session must be expired and the client must not be able to call any EJB on the server until new successful log-in.
    You could use a statefulSession bean as the facade with Command pattern. Pretty nasty but it would work.

    Solution with StatefullSession bean and command pattern is really nasty. As I understand it is possible to mark stateful session bean as "expired" only in the ejbPassivate, because ejbRemove may not be called at all (according to specification) if bean is disposed from "Passivated" state. Or I'm wrong here?
  5. Re: Write Your Own[ Go to top ]

    ejbRemove won't be called if RuntimeException, or as you say, if passivation times out.

    You don't want to mark it in ejbPassivate because that is only called by the container, not by you and it may be called many different times during it's life.

    I wasn't really suggesting to go with Stateful + Command because I couldn't sleep at night :) If it is that critical go with JMS.

    You are right, it is a glaring whole in the EJB spec :(