Exactly Phillipe,
Typical example where we have encountered this was, e.g. poolmax = 300 but
table had 400 rows
Then when we did
For (Enumeration enum = MyBeanHome.findAllinTable();
enum.hasMoreElements();)
{
((MyBean)enum.nextElement()).doSomething();
}
we got in Weblogic exception about cache being full. It could be I guess due
to sloppy Enumeration implementation as well, since we didn't hold all
instances at once, but clearly it didn't work and so we moved from Weblogic
(4.5.1) to Jonas 8-)
Miro Halas
-----Original Message-----
From: Philippe Durieux [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 23, 2001 4:53 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Re-2: Proposal for Jonas Container Improvement
[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".
----
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".
