> > > > [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.
Maybe I not quite talk about the same as you do. Can we clear this first:
POOL means the collection of preallocated objects for later reuse, to prevent
allocation time.
CACHE means the the collection of ready to use, fully loaded with user data, entity
beans, to prevent re-loading time.
poolmax and poolmin are working on POOL, not on CACHE.
Is this correct?
So I was wrong with my last mail, I talked about CACHE, not POOL, but you meant POOL.
Okay, so what I still do not understand is, why you want to enlarge the pool then
temporarily (I thought you wanted to enlarge CACHE)? If I re-interpret your mail
("...allocate anyway..."), I think actually you do not think nor enlarging POOL
neither CACHE. That's what I think it would be good. I do not understand, for what you
want to enlarge POOL or CACHE over a MAX value, since the transaction can use
instances than are neither in POOL nor in CACHE. Would there be a benefit of having it
temporarily increased or is it just a must because of your planned implementation?
My idea was to push EVERY loaded entity into CACHE; if CACHE would be oversized, it
pushes out old entries; it does not grow over CACHMAX. If the transaction is ready,
the entity is kept in cache. If an entity is pushed out of CACHE, it is pushed to
POOL. If POOL gets oversized, the entity gets freed (and GC will eat it up). So
maximum memory allocation would be CACHE+POOL for preallocated objects, plus currently
"IN USE" objects that are not in CACHE since CACHE is too small to hold all processed
objects at one time.
So from my point of view, we need:
POOLMIN, POOLMAX, CACHEMAX.
The first two are for POOL, the second two for CACHE. CACHEMAX is the absolute upper
limit of CACHE, so CACHE can grow from zero to CACHEMAX objects. POOLMIN is the
preallocation of POOL at JOnAS boot, POOLMAX is the absolute POOL upper limit. One
could imagine CACHEMIN, what would lead to a prereading of objects out of the
database; but I do not think something like that makes sense.
I do not want to criticize your solution, I just want to understand. :-)
Thank you
Markus
P.S.: Maybe we should draw a sketch of that... :-)
> 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]
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".
