Application context in cluster (using EJB3.1)

Question

Hello there,
i want to ask for recommendation. What is the best strategy for storing global application data in clustered enviroment with usage of EJB3. Imagine e.g. users and contact lists. There are browser clients (let's say they invoke EJB from typical servlet) using polling mechanism (it's HTTP, i dont know about solutions how to do effective server push) - so asking application server again and again for refreshing their contact list.
I know that there is @Singleton beans and with this approach you are telling the server provider to take care about it. But im afraid with this approach it could be uneffective because nodes of cluster propably replicate those singletons or has to do some other expensive network operations. Or don't they?
Is @Singleton effective for such case? Or any mechanism like JMS topic could help me update data on clusters? It would be really nice to have it in application context somehow effectively. What do you think about it? Thank you:-)

Answer 1

ok, you suggested that contact list can (and maybe should) be placed within user session. It is true that contact list itself does not change much but what changes very frequently is who is currently online (users performing login and logout). So the main question leads to this problem. The stuff user's status could be linkend with contact list was just a idea, but it is not needed.
So now the problem, information who is logged in and how to periodically with good performance in cluster enviroment retrieve such information (in context of getting whole contact list with corresponding actual statuses for one specified user). What solution would you choose from the beginning? Just please try describe two scenarios and invocations.
1) user logs in
2) periodicaly request for updating contact list
E.g. (this is just showcase corresponding to previous posts)
Data who is and who isn't logged in is stored in database (e.g. column STATUS).
1) servlet invokes EJB login method. That puts message to JMS topic that user A just logged in, updates DB (changing status to online), than the method returns UserData retrieved from DB which will be stored within http session including contact list. The MDB (stored within EJB module?) in onMessage method recieves information that this user A just logged in, it will update http sessions (is it even possible to do somehow from ejb module?) of users which have user A in their contact lists - e.g. contact lists of user B, user C and user D.Maybe I did not state it explicitly in my previous post. But it is not possible for an MDB which receives a message asynchronously to access the HttpSession object. Besides which Session object are you going to update? As you rightly said, the new user who is online may be in the contact list of several other online users.
It's not that this is not possible to achieve - you can store a handle to these session objects globally (possibly in a static Collection accessible to the MDB layer) and iterate through each session object, figure out if the contact list in the user session does contain the newly logged in user as a contact and update the status accordingly.
But there is an easier option - you just maintain the list of active users in a cache. And everytime the user makes a request, check the contact list of the User (maintained in his session object) against this list of active users. For every user who is both in the contact list and active users list, you just update the status of the contact as active. Is that what you had asked initially :)? Only your last post made clear what you were trying to achieve.
You would maintain the active list of users using a JMS Topic/MDB listener mechanism. Note you will have to propogate the log off/session invalidation too to remove users from the active list.
2) periodical request will come on http session (it contains actual data because it is updated by MDB (if it is possible somehow) )Just use ajax to poll the server and then as mentioned above - for every request, check the contact list held in session against the active users list.
cheers,
ram.