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.

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

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.

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?

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 :(