[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.
>
> 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?
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.
Maybe I should not call this poolmax if it's too confusing ?
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.
>
> 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...
>
> 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. :-)
Again, I'm not sure we need both poolmax and cachemax (see upper) but may be I'have
missed something.
>
> 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".
--
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".
