> "Halas, Miroslav" wrote:
>
> Hi Phillipe,
>
> this is great news. I put more comments into your email. Thanks for your effort,
>
> Miro Halas
>
> -----Original Message-----
> From: Philippe Durieux [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 21, 2001 4:33 AM
> To: jonas-users
> Subject: Proposal for Jonas Container Improvement
>
> Hi all,
>
> I've read all your mails about tuning JOnAS for improvement,
>
> thanks to all contributors. I was thinking to modify JOnAS
>
> that way, to take into account your remarks:
>
> Add in the JOnAS specific deploymenty descriptor 3 new tags:
>
> For each entity bean, we could define:
>
> shared: Y/N
>
> poolmax: max nb of instances in memory
>
> [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.
>
> poolmin: min nb of instances preallocated
>
> Then, we could change the policy when beans are not shared, by
>
> keeping the bean instance "ready" (cached) and pre allocate at
>
> bean loading the min nb of instances in the pool of available
>
> instances. THe poolmax value could be used to limit the nb of instances
>
> in memory, this for scalability.
>
> If we analyse more deeply the code, this could be something like
>
> this:
>
> getContext():
>
> if already mapped -> OK
>
> else if instance in the pool: get it and read state.
>
> else if count < poolmax: create a new one and read state.
>
> else clean instances not used to decrease count
>
> and then, create a new one...
>
> [Halas, Miroslav] This will be an interesting problem because we would like to
>release those
> instances which are not used often so there will need to be some either usage count,
>last used
> time, round robin like mechanism
Sure. Many options can be considered here.
>
> releaseContext():
>
> if bean shared: store state and put instance in pool.
>
> else keep it "ready" for use (but releasable if count
>
> become too big).
>
> Actually, it's more complicated, because we have to deal with
>
> transaction/no transactions, but it seems that all this could
>
> be done. What do you think ?
>
> [Halas, Miroslav] I can almost guarantee that this should increase performance f our
>application,
> it will be interesting to see how effective it will be.
>
> --
>
> 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".
--
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".
