hi i have a situation where in i should avoid the user from loggin in for the second time, there are some restriction on how to do that, they are
i cannot use cookies
i cannot use LDAP
i cannot use a seperate table in the database.
can i acheibe this using Listener or Filter
any direction would be greatly helpful
I think most people would use sessions, and a session listener to cover users closing the browser withoug logging off (killing the session)
You could do other things like put a flag in a database, with a timestamp (in the same table as the users details perhaps).
You could use the timestamp to allow users to log on 'twice' after a given abount of time.
You should consider using time stamps or some other 'timeout' machanism to handle users who close their browser without logging off (assuming you use a log off button to reset the database flag and kill the users session).
i dont want to use any fields in the data base as it effects the performance of the system,
i would like to have you comments on the following:
i will store a hasmap in session, which will store the user id and the session id of the user, so whenever a user is trying to login i will check for that user in that hasmap and check whether the session id is still valid, depending on that i can avoid second login.
any help would be greatly helpful
> i dont want to use any fields in the data base as it
> effects the performance of the system,
Can you write to a file instead (which should be faster for this kind of data)
> i would like to have you comments on the following:
>
> i will store a hasmap in session, which will store
> the user id and the session id of the user, so
No, if you store the hashmap in the session, it will be specific to that user.
If the users opens anther browser session, they will get a new (second) session, a new hasmap, the two hashmaps will not 'see' each other, and you will allow two logins.
If you dont want to store data in files, you could use a SINGLETON CLASS.
Only one instance of a singleton can exist at any one time (so will be shared by all users).
You could use this class to store details in a hashmap or array. You would then need to access this class from your JSP, this can be done with the USE BEAN directive.
Creating singletons is easy enough, you get the class to look for an instance of itself prior to instantiation. To do this you create a method within the class which is called by the jsp accessing it, a short example:
/**
* A singleton class
*/
public class singletonCreatePool{
public static DataSource dataSource; // Define your hashmap / array here
/**
* Method to return instance of class.
* If no instance exists, instantiation occurs.
*/
public static singletonCreatePool getInstance() throws Exception
{
if (instance == null)
{
instance = new singletonCreatePool();
}
// do any stuff you need to with the instance of the class
return instance; // before returning the instance
}
You would access the singleton from your jsp with something like
singletonCreatePool.getInstance().getYourMethod();
In the code above getYourMethod() is another method within the same class.
You would write set and get methods as normal for your class.
Because the above line puts getInstance() before getYourMethod() you always access the same instance, never creating more than one.
I hope this makes sense, if you search the forums you will find better code examples.
Post your solution back here when your finished!
guys, I am not sure but just sharing my veiws.
Is it possible to create the session with a Id for each user, and add it to the hash map object.
Then set the object as Application scope, which will be available till the application lives.
So when second attempt is made for the existing user, check it with the hash object and reject the second login.
> guys, I am not sure but just sharing my veiws.
>
> Is it possible to create the session with a Id for
> each user, and add it to the hash map object.
> Then set the object as Application scope, which will
> be available till the application lives.
> So when second attempt is made for the existing user,
> check it with the hash object and reject the second
> login.
Yes that would be an easier way of doing it.
> the hashmap technique is fine, but as the number of
> users grow it will result in performance issue.....
> any better ideas to solve the same
That's the best option you have got. And as for the hashmap growing, remember that you'll also be removing the entries when a user's session ends.
And if the number of current users do incease to a point where the hashmap slows down, I think you'll have bigger problems at that point of time than wooring about the hashmap performance :)
Finally angrycat, that getInstance() method in your singleton post has to be synchronized to make it perfect :)
ram.
We had a similar type of situation in our project.
Initally we had defined static maps in the business tier to hold the Logged in user information, and we used to check when any other user wants to log in.
It works and scales well, but slowly we have realised that there are problems with Clustered Servers, since in Clustered Environment, every node has its own JVM, these static maps approach is no good, because if the same user's request goes to the second node, he will be able to log in because the static map in the second node will not have his information.
So we had to switch the approach of Map with database, something like storing the logged users info in Logged_Users table , even File system is a good idea, but File system calls will be very slow, so they should always be avoided to database calls.
We have removed the entry of the user from the database when he logs off from the system or when his session expires. We used to have SessionBindingListener to trigger the Session Expiries
But again we had another big problem, what happens if one of the node crashes where some users are connected through it. They will permanently be locked in database,
So we also stored the information of each node from where the user is logged in the Logged_Users table, and when the node is restarted we are deleting all the users that are against this node from the database..
Regards
Cva
