• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

Get previous session with the Session Id

 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I have a scenario where i want to restrict the login second time by the same user. In this case, i want to invalidate the previous session. But using the getSession(sessionId) method of the HttpSessionContext, I get a null value. This is because the API is deprecated.

So, nothing can be done using the HttpSessionContext. I have already stored the sessionId of the previous session in the database. My problem now is that i need to get the previous session which has its sessionId stored in the database, so as to invalidate that session.

I hope my problem is clear to you guys out there. Is there any way out for this issue? Could anybody tell me what to do? What could be the solution for this problem?

Thanks.
[ October 06, 2004: Message edited by: Sherryl Philip ]
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Communication between sessions isn't possible for security reasons.

The best you can do is keep a list of logged in users somewhere and clear the userids from this list when their sessions are closed (they log out) or time out (they're killed).
Of course this isn't perfect as a user may close his browser inadvertently and will then be unable to log in again until the other session times out.
One way around this is to check with each request if the user is known with his session id in the list and forward to the login screen if not.
Then you can give an option "kill previous login" on the login screen which (if username/password are correct) removes any existing entries in the table of logged-in users.

This table could simply be a static hashTable for the web application keyed on username and containing the session ID as a value.
 
Ranch Hand
Posts: 1228
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sherryl Philip
Threedays back only i have solved this problem in my prj ..
This is wat i did :

Created a SessionListener, that gets notified when ever a session gets ceated or destroyed.
When ever the user login in the Application, the session id is stored in the DB for that user .
1. When the user log's out Session is cleared (invalidated ) so the sessionListener gets notified So i'm Clearing the SessionId that is stored in the DB for that user.
2. When the session gets timed out . Again the SessionListener gets notified and the same happens.

3. Now this scenario, User closes the browser inadvently :
A new window is opened througn the Unloadevent & in that window the session is cleared.(This can work if the site/Application has a static frame ) So in the static frame Unload event U can open a new window that clears the session.

This is working well for me..

The only problem i face is when ever the application is being reployed or undeployed the listener is not getting notified, so the users who have logged in at that time face some problem after the appln gets deployed ( session id is in DB it's not cleared ).

Srini
[ October 06, 2004: Message edited by: srini vasan ]
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by srini vasan:
3. Now this scenario, User closes the browser inadvently :
A new window is opened througn the Unloadevent & in that window the session is cleared.(This can work if the site/Application has a static frame ) So in the static frame Unload event U can open a new window that clears the session.



doesn't work reliably.
We were thinking of the same thing to clear database logins when users close their browsers without first logging out and it turned out the window close event from Javascript isn't always called when a window is closed.
It depends entirely on what mechanism is used to close the window (javascript call, menu, close icon, process kill).
 
Sherryl Philip
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,


Created a SessionListener, that gets notified when ever a session gets ceated or destroyed.
When ever the user login in the Application, the session id is stored in the DB for that user .
1. When the user log's out Session is cleared (invalidated ) so the sessionListener gets notified So i'm Clearing the SessionId that is stored in the DB for that user.




Well, thanks for the solution. Actually, I have been trying to do the same thing, without the SessionListener. But now my concern, is to restrict the same user login same time without logging out the first one, in which case I want to invalidate the user's previous login session, make it available in the second login. That is restrict the user's multiple login.

The best you can do is keep a list of logged in users somewhere and clear the userids from this list when their sessions are closed (they log out) or time out (they're killed).



I'm already storing some values in the session, so storing the sessionId will again cause performance issues, when so many sessions are maintained in the server.

Thanks for the help.
 
Sheriff
Posts: 67752
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

storing the sessionId will again cause performance issues



You have hard data to support this supposition?
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Say you're storing 10000 sessions (meaning 10000 simultaneously active users, which is a LOT).

SessionID is a String, maybe 20 long.
UserID is a String, maybe 10 long?

That's 60 bytes (using 2 bytes per character as Java does) times 10000 or 600 kilobytes.
This data is already in the string constant pool for the JVM so you don't loose that amount of memory

Remains the memory for a single HashMap with 10k entries which is just over 40KB (10K times 2 times 2 bytes plus a bit for the HashMap itself).

Time to look up whether a userID exists in the Map is a very short, and can be regarded as being zero if you do any database or network operations in your application.

Is there impact? of course, every line of code you write that's not optimised away by the compiler or dead code will have an impact.
Will it be measurable? Not likely, unless the rest of your code is trivial.

Will you likely loose this much memory? No. As I said 10K users is extreme, unless it's an intranet application for a major government agency that everyone there will use all day long constantly you're unlikely to have more than a few hundred simultaneous users for even a large application.
And if you do, you should be clustering your app anyway and use far more elaborate (and expensive in resources) schemes for security like EJBs.
 
Not looking good. I think this might be the end. Wait! Is that a tiny ad?
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic