The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:Welcome to the JavaRanch, Babu. We'd prefer that you use your actual last name instead of just an initial letter, though.
J2EE does not maintain a continuous connection between client and server (actually, no HTTP-based system does). So you can't sever that (non-existent) connection to force a logout.
The only way to log out is to discard your security context, which generally means to destroy your HTTPSession object.
Probably your best bet would be to keep a list of all logged-in users, and when an attempt is made to login a user ID that's already listed as logged in, you'd have to set some sort of indicator that causes the next request from the old location to be redirected to a logout process. Only the server or the logged-in user can log out the user, no other user can do so (safely and portably, anyway!). So you can't do an immediate logout, only a scheduled one.
In actual practice, it's more common to reject the second login instead of forcibly terminating the first login, since there may be work in progress that should be saved over on the original user login. Some systems have been set up to force out an existing login, but they normally ask permission first, so that there will be an option to save whatever that work in progress was.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:That sounds like a somewhat different problem.
Because of the immediacy of the HTTP request/response paradigm, a user cannot (reliably) hold onto a database connection or transaction for an extended period of time. However, in the case of a workflow consisting of multiple views (and extended transaction), you may have to do one of 3 things:
1. Break the transaction down into separately managed parts.
2. Lock the affected resources for the life of the extended transaction.
3. Ignore any other actors and proceed onwards, letting them handle the consequences.
Solution 2 is the least common, since it can lead to deadlocks. Solution 3 has the drawback that unless you're careful, the consequences don't get handled properly.
If you're using a sufficiently powerful database and an extended transaction driver/environment, some or all of the issues involved in extended transactions may be automatically handled for you. One of the things you can do if that isn't enough, or isn't an option is to provide your own interlocks as well.
You can set up a hashtable at application scope where the keys are user IDs and make entries into it (using synchronized resources). And/or you can set up a similar resource access control facility if you're more interested in limiting specific resources instead of users. Things that can help are:
A) A servlet filter. If you're using container-managed security, the HttpServletRequest userId will contain the userID (or null, if the user isn't logged in).
B) A session listener. This allows you to remove a user from the control tables when they're logged out (whether explicitly or when the session times out).
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |