"Bordet, Simone" wrote:
> the cache policy (i.e. the algorithm used to decide when a cache entry
> should age out of the cache, and hence passivate a bean) and the cache size
> should be something manageable in jBoss, or it is not the case ?
This is configured in the "Container configuration" settings in the
jBoss deployment descriptor.
> For example, should a sys-admin be able to manage through JMX the jBoss
> server and change its cache sizes or policies at runtime or this is a
> feature not requested / important ?
I have a few issues with this. First of all I'm not sure its the
sys-admins task to do this. I think this is something to be determined
by the deployer, hence these settings are contained in the deployment
descriptor. Also, being able to change these things arbitrarily at
runtime would make it much more likely to cause strange bugs. Therefore
I would prefer that IF these changes should be made, they should be made
in the deployment descriptor, and then the bean should be redeployed.
This is the only way to ensure a consistent behaviour.
That said, if a particular cache was designed so that it would be
possible to change this at runtime, then that would be ok. It would just
have to be carefully coded so as not to break anything. It would also be
tricky since a redeploy would reset the settings to the values in the
deployment descriptor.
In short: it is possible, but I wouldn't recommend it.
> I remember a post of Rickard saying that could be an option for the cache
> size, what about the policies ?
The above only discusses the possibility to change this at *runtime* of
a *running* application. If we instead say that we want to be able to
configure these things at deployment time, that is a different matter
entirely. And the fact is that this is already available. In the
container configuration settings you can choose which cache to use, and
each cache could use different policies and different sizes. Currently
the options are "no passivation" and "random". This list will be longer
later on with options for "LRU", "NRU", and "FIFO". At least.
Does this answer your query?
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
