marc fleury wrote:
> |In fact, when the cache max capacity is too small, I end up in a situation
> |where all cached beans are active (eg involved in a call) and a request to
> |insert another one arrives.
> |Here I kick out of the cache the last one, but I cannot passivate it, so it
> |will be reinserted in cache, causing the now last one to be kicked off the
> |cache, and so on.
> 
> I see, you know given the fact that most caches will run on big machines I
> don't see why the "max size" should be a hard limit... it introduces
> artificial problems.  I am all for removing the "max"

Same here.

> |What will be in your opinion the best way to handle this ? I mean
> |what would
> |you like to see as warning and what would you like jBoss do (eg,
> |undeploying
> |the bean, stopping, enlarge the max cache capacity temporarly, send cursing
> |email to me, etc :)
> 
> enlarge the max, in fact remove the max requirement.  What is the purpose,
> that we don't run out of memory :)))

Preferably it should be a working set, i.e. use the bean a lot then it
gets more resources. But there is a need for a max, since what would
happen if 500 EntityBeans were used at the same time without max!?
Kabooom.

> |Marc, when release 2.1 is planned ?
> 
> I am shooting for the end of this week.
> 
> Rickard stuff with EJX needs to make it in, some andy stuff, the roberto
> work, some deployer stuff and this would be great...

I will get the server conf stuff in, but not EJX. Getting the EJX stuff
working is doable, but then there's the whole porting of JBoss metadata
usage... wheee.... I guess we could ship the new EJX *GUI* though, and
wait with the metadata usage in the server a bit.

/Rickard

-- 
Rickard �berg

Email: [EMAIL PROTECTED]

Reply via email to