> > [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.
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".
