• Post Reply Bookmark Topic Watch Topic
  • New Topic

Single reference between Instances  RSS feed

 
Martin Turner
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I want to ensure that customers to my site logon once only. We are running WAS (4 or 5 to be determined). I do not need to persist the data outside the session as it is only for control purposes so, effectively want the same singleton instance across all instances.
I am considering using a simple Entity Bean (customer ID as the key) that doesn't have DB access. Any comments? Would this perform adequately for a large enterprise?
Martin
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I do not need to persist the data outside the session as it is only for control purposes so, effectively want the same singleton instance across all instances.
Huh? Could you explain what you mean by "same singleton instance across all instances"?
I am considering using a simple Entity Bean (customer ID as the key) that doesn't have DB access. Any comments? Would this perform adequately for a large enterprise?
If you mean that each user would create an entity bean using their customer ID as the primary key to indicate that the user has logged in, you'll run into trouble when the user tries to re-login; the entity bean is persisted in the database beyond the client session. Let's say a client called "Martin" logs in and your application creates an entity with primary key "Martin". He uses the application for a while and then closes his browser. A minute later he remembers something he forgot to do and tries to login to the application again. Oops. Duplicate primary key exception, cannot create another entity using primary key "Martin".
 
Martin Turner
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Apologies for bad explaination of the problem. Your assumption is correct regarding my question.
The actual requirement is to prevent people from logging on more than once so that the second logon would be justified in invalidating the first. If we assume that the two logons happen from different http sessions then we can hold the session ID in the bean in order to check that the active http session for the given user is the http session that we are active in.
As the user id / session id is transient data I don't want to have to persist it to an external database if avoidable (there are other reasons why I don't want to have to do this as well). However if the DB is part of the WAS clustering then this will probably be acceptable.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The actual requirement is to prevent people from logging on more than once so that the second logon would be justified in invalidating the first. If we assume that the two logons happen from different http sessions then we can hold the session ID in the bean in order to check that the active http session for the given user is the http session that we are active in.
As the user id / session id is transient data I don't want to have to persist it to an external database if avoidable (there are other reasons why I don't want to have to do this as well). However if the DB is part of the WAS clustering then this will probably be acceptable.

I think I see your point now. I'll just say it aloud to be sure we're talking about the same thing... So, you thought of having a "LoginEntity" which consists of two pieces of information: user ID and session ID. Every login procedure would cause either A) a new LoginEntity to be created, or B) the existing LoginEntity being replaced (with the same user ID but a new session ID).
Would every request would check that the LoginEntity for this session still exists in the database? This sounds somewhat heavy (though I can't think of a better way either) performance-wise.
I think the entity bean would need to use a database. What did you have in mind as an alternative?
 
Martin Turner
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You have got the requirement! Unfortunately every request would have to check the database to ensure that the session is still active. The only other model that I have thought of is a 'notification' model where an deactivated logon would notify the appropriate http session which would then invalidate itself.
Regarding the use of the database behind an entity bean, this shows up my experience level. I was hoping that if I used CMP the container would implement this for me within the appropriately clustered instances. What I am specifically trying to avoid is implementing our own database.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The only other model that I have thought of is a 'notification' model where an deactivated logon would notify the appropriate http session which would then invalidate itself.
The notification model would be the best choice if we had a way to implement it... At least I am not aware of any (non-proprietary) solution for invalidating HttpSessions from other HttpSessions. Except... I actually came up with an idea while typing. Would it be possible to generate an HTTP request to "http://localhost:1234/servlets/MySessionInvalidater?jsessionid=ADAGADGASDFAS" from the login handler using the session ID listed in the database? I guess it could be done although I am not sure exactly how easy/portable such a solution would be.
Regarding the use of the database behind an entity bean, this shows up my experience level. I was hoping that if I used CMP the container would implement this for me within the appropriately clustered instances. What I am specifically trying to avoid is implementing our own database.

If having a database isn't the problem per se (i.e. you've got an existing licence or you can use a free/OSS database such as PostgreSQL) then by all means go with that. It's probably a lot easier than writing a BMP using some in-memory database (remember that the in-memory database has to be clustered). Furthermore, CMP can provide you with a pretty good caching layer even across the cluster.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!