> > Is this correct?
> poolmax concern all instances in memory (cache + pool) because it doesn't
> matter
> for me if instances are available or ready instances, they use the same
> amount
> of memory.
Well, THEN I understand even better. :-) I was confused by the word POOLmax.
> Maybe I should not call this poolmax if it's too confusing ?
Yes, it would be better to talk of... well... cacheandpoolmax...? Maybe we can find a
better word, but at the moment I have no idea. May there be instances in POOL when
CACHE is at it's upper bound? I mean no. So would it be correct to call it CACHEMAX?
> poolmin concern only the pool, because I don't see which instance we could
> map
> when the bean is loaded. It's just to improve a little performances by
> avoiding
> creating new objects for the first requests on the bean.
That's clear, since I proposed this last week... ;-)
> > 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.
> >
> What are these "in use" objects ? For me, as today, all instances used by a
> transaction must
> be mapped in memory, so they are all part of the cache. Jonas cannot work
> if not. Or maybe
> I don't understand what you mean...
IN USE means objects that are currently used by a transaction, so you can say, if you
take an entity out of CACHE or out of pool and load it with DBMS data, what you will
get is an IN USE object. If we have a transaction that loads 3000 entities and we have
POOL limited to upper 1000 entities and we have CACHE limited to 2000 entites, you'll
get this result (from scratch):
- 1000 entities are taken out of POOL, filled from DBMS with user data, put into CACHE.
- 1000 entities are new allocated since POOL is empty now, filled from DBMS with user
data, put into CACHE.
- 1000 entities are new allocated since POOL is still empty, filled from DBMS with
user data, put into CACHE, but CACHE is already full, so CACHE drops 1000 old entities
and puts the 1000 new entities in.
- Then you'll have an empty POOL, 2000 entities in CACHE, 3000 entities IN USE.
So as you can see, all entities are in memory, but are not in CACHE. Also, this is not
needed. CACHE is to prevent reloading from DBMS only, not for N-times reading the same
bean inside of the same transaction. The transaction doesn't need CACHE, since it has
all what it needs IN USE. Some of that IN USE actually are in CACHE, but the
transaction does not care about. Only the next starting transaction cares about: This
maybe wants to have 1000 beans, 500 of them are already in CACHE, so it takes them as
they are right out of the CACHE. If there would be no CACHE, the transaction would be
forced to load from DBMS, and this is where all this discussion task started. But even
if there would be no CACHE, the transaction would hold its referenced entities in
memory for that it needs not to reload from DBMS every two seconds (this is what JOnAS
does at the moment).
Is it clear now, what I mean?
> Again, I'm not sure we need both poolmax and cachemax (see upper) but may
> be I'have
> missed something.
If I think about it, we only really need this (in my terms):
POOLMIN to preallocate POOL at JOnAS boot
CACHEMAX to upper limit (absolutely, no excused) of CACHE
If CACHE is fully loaded, POOL may be empty, no problem. CACHE will not exceed
CACHEMAX since transaction will use IN USE (uncached, but in memory) then. POOL will
be empty until JOnAS stops or by some feature we clear the cache without need and
re-pool that entries into POOL (but I don't know for what).
Thanks
Markus
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".
