Hi Philippe,
thank you for your comments. More embedded.
> 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
Actually, this will solve Miro's need to have the shared flag provided for each single
table instead of the common database. Unfortunately, this will lead to the problem,
that this information can be inconsistent: If one bean in one container tells to be
shared, and another bean in another container tells to be not...?! This could only
avoided if the flag is not given in the deployment desciptor, but the
database.properties file, since this file is shared between containers in the same
JOnAS server.
> poolmax: max nb of instances in memory
ok
> poolmin: min nb of instances preallocated
ok
> 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.
ok
> 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...
For I am no JOnAS-source specialist, I do not know of what getContext is for, but what
it does sounds correct for me. What I would suggest would not to have two paths that
load stat but only one:
if already mapped -> OK
if count >= poolmax: clean instances not used to decreased count
create a new one and read state.
This is shorter and less complex.
> releaseContext():
> if bean shared: store state and put instance in pool.
> else keep it "ready" for use (but releasable if count
> become too big).
For I am no JOnAS-source specialist, I do not know of what releaseContext is for. So
to be explicit, I will tell what I think it should do in normal words:
in any case, if TX is committed, store back data to the DBMS
in any case, if TX is rolled back, forget the data
if bean is shared, put the instance into the pool
if bean is not shared, keep the instance in the cach and mark it "ready" to use
(sure it is releaseable if count becomes too big).
Maybe this is what you meant, but it was not clear to me.
> 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 ?
I think that this is quite what we would like to have! 8-)
Thanks a lot
Markus
To: [EMAIL PROTECTED]
[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".
