[EMAIL PROTECTED] wrote:
> 
> > > [Halas, Miroslav] Just one comment. Please avoid pitfall which was present
> > > in Weblogic (I think
> > > 4.5.1). The poolmax is just suggested value, but you have to be able to
> > > actually create and manage
> > > more instances than specified by poolmax. Example where it happens is when
> > > you run a finder which
> > > returns more values than poolmax. There was a bug in Weblogic where WLGC
> > > increased the size of the
> > > cache but still threw an exception that the size is full.
> > I agree. The poolmax may be just a suggested value. If we need more
> > instances, we
> > allocate them anyway. But when these instances are not used anymore (i.e.
> > when
> > transaction is committed), they are always passivated and discarded in
> > order
> > to try to reach the poolmax again.
> 
> If I understand right, the intention is to have a temporarily enlarged cache so that 
>the running 
> transactions can work fully out of the cache, is this correct? I did not thought of 
>such a feature, but why not, it sounds good. The problem I see is that if there are 
>transaction that uses very large lists of entities, the cache will grow so much that 
>it will reach the physical memory limit. So we have to check this. That's why I 
>thought that it would be easier to not check for the memory limit but the poolmax 
>property only (since I can imagine that asking the VM for the memory limit is quite 
>time consuming), but hey, if you find this better, it's ok for me.

Yes. It's what I intend to do. The other solution seems to raise an exception
when the limit is reached, but this seems too bad, and I see Miroslav agree with me.
But if you reach the physical memory anyway you will have problem (as it's
the case today).
There is a third solution: When the poolsize is reached, the calling thread is
put waiting until the count has been decreased. But again, this will not
work if one thread ask for more than poolsize instances in 1 operation!
So, I prefer stay on the 1 option: temporary increase the cache, and decrease it
asap.
> 
> To: [EMAIL PROTECTED]
>     [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> 
> ----
> To unsubscribe, send email to [EMAIL PROTECTED] and
> include in the body of the message "unsubscribe jonas-users".
> For general help, send email to [EMAIL PROTECTED] and
> include in the body of the message "help".

-- 
Philippe Durieux  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Bull - 1 rue de Provence - 38432 Echirolles Cedex France
[EMAIL PROTECTED]
-> Download our EJBServer at http://www.evidian.com/ejb <-
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".

Reply via email to