This content has been marked as final.
Show 6 replies
-
1. Re: Caching data per user - multiple instances or not?
manik Mar 12, 2007 2:17 PM (in response to augustientje)Which app server do you use? If you are using JBoss AS, we use JBoss Cache behind the scenes anyway to replicate your user session data.
-
2. Re: Caching data per user - multiple instances or not?
augustientje Mar 12, 2007 8:15 PM (in response to augustientje)"manik.surtani@jboss.com" wrote:
Which app server do you use?
The code in question is meant to be app server independent, so that's why I didn't mention a specific one.
If you are using JBoss AS, we use JBoss Cache behind the scenes anyway to replicate your user session data.
This surely sounds interesting. It's probably the reason why with JBoss AS you don't have to explicitely put an object again in the Http session after you mutated it in order to get it replicated, right? -
3. Re: Caching data per user - multiple instances or not?
manik Mar 13, 2007 9:41 AM (in response to augustientje)
It's probably the reason why with JBoss AS you don't have to explicitely put an object again in the Http session after you mutated it in order to get it replicated, right?
Depending on how you've configured JBoss session replication, yes.
The JBoss http session replication codebase is probably where you want to look if you're interested in implementing something similar yourself in an app-server independent manner using JBoss Cache. -
4. Re: Caching data per user - multiple instances or not?
augustientje Mar 13, 2007 7:36 PM (in response to augustientje)"manik.surtani@jboss.com" wrote:
It's probably the reason why with JBoss AS you don't have to explicitely put an object again in the Http session after you mutated it in order to get it replicated, right?
The JBoss http session replication codebase is probably where you want to look if you're interested in implementing something similar yourself in an app-server independent manner using JBoss Cache.
Well I don't really need the replication. My usecase is that the existing application I'm using JbossCache with is storing a lot of stuff in the session. It's really an overstuffed session anti-pattern, but I can't easily fix that now. Where I would like to use JbossCache for, is for putting an automatic limit on the number of objects in the session. Its eviction policies are probably exactly what I need.
So my original question remains; what would you suggest? Creating a cache instance per user or one global instance with a node per user? -
5. Re: Caching data per user - multiple instances or not?
manik Mar 14, 2007 9:09 AM (in response to augustientje)Global instance, node per user.
-
6. Re: Caching data per user - multiple instances or not?
atijms Mar 14, 2007 11:44 AM (in response to augustientje)"manik.surtani@jboss.com" wrote:
Global instance, node per user.
Indeed, you definitely need to go with a global instance. The thing is that if you're using an EvictionPolicy, JbossCache will create a Timer thread for each instance. If you go with the instance per user idea you'll probably end up with a lot of threads in your system.
The disadvantage of the single instance is indeed that you need to clear the cache yourself when the user's session ends. Two ways to help with that is setting the time to live for each node programmatically to the same value as your session timeout and installing an HtppSessionListener that removes the entire user node at the sessionDestroyed event.