[EMAIL PROTECTED] wrote:
>
> > > 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).
Thanks for explanations.
Just some additional remarks because I'm still not sure we talk the same
language:
1.
I call CACHE the set of instances that are mapped
in memory, each of them corresponding to a different PK. Some of them are
used currently in a transaction, some others are not in a transaction, but
have a good state and are not to be reload from DBMS. They can be ready to
be used by a new transaction, or to be used outside any transaction.
I call POOL the set of instances that are no more associated to a PK. They
can be reused for any PK.
In your example, if my transaction needs 3000 instances, I need 3000 elements
in CACHE. So if my limit (POOL+CACHE) is 2000, I will temporary increase this
limit by allocating 1000 new instances. Later, (when transaction is over),
I will free at least 1000 instances to retrieve my theorical limit of 2000.
May be you have better ideas for this, but currently I intend to do this...
2.
If your bean is not shared, the pool is not used most of the time,
because we keep as much as possible instances in CACHE. The pool is heavyly
used for beans that are declared as shared: At each commit, all instances
are moved from CACHE to POOL. But the source code is quite the same, so we
deal with POOL and CACHE the same way in both cases.
3.
What I want to do is
to keep jonas code simple and easy to understand, because JOnAS is an
opensource project, and we want that a maximum of users can easily deep into it
and even propose improvements.
BTW if you want to have a look at the current code, it's in
objectweb/jonas/src/org/objectweb/jonas_ejb/container/*.java (look at
ContextSwitch.java)
This code will have to be changed to implement all this...
4.
I'm not sure that what I am doing is the best choice, and every
remark from jonas users is welcome and will be examined.
Thanks a lot for your interest in all this.
>
> 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".
--
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".
