Philippe:
> 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.
Okay, if you want to call that CACHE, then I agree with you that there is a need to
temporarily oversize it.
My defition of CACHE was that it is an additional buffer (additional to that memory
JOnAS needs already to work at all). I'm not quite familiar with your definition of
the word CACHE, since everywhere you look in the IT world, a cache is an additional
feature, regardless of the normal memory usage (e. g. the RAM cache in PCs is
additional to the RAM; the track cache of a CD-Drive is additional to the memory
needed to process/decrypt the music data etc.). So I was somewhat confused of reading
of temporarily oversizing it... But okay, you'll call CACHE the complete workspace
plus my definition of CACHE and so your intension is correct. :-)
> I call POOL the set of instances that are no more associated to a PK.
So do I. :-)
> They
> can be reused for any PK.
ok
> In your example, if my transaction needs 3000 instances, I need 3000
> elements
> in CACHE.
In your definition of CACHE, yes, correct.
> 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...
Yes, implement CACHE separately as my defition of the word. Then in future one will be
able to change the CACHE implementation without having to change to whole container.
We could do a simple CACHE interface to manage this, and the whole design would be
more look more clear. Maybe this will interfere with current JOnAS design, I don't
know, but this will lead to not having to deal around with changing oversized cache,
since there will be no oversized CACHE, but only (in my definition) IN USE items that
are not cached, that means, if the transaction is over, POOL will be filled up with
them, and what is more than POOLMAX is just thrown away. This will have the same
effect, but will be very more straightforward and easy to read and implement (from my
view; I do not know current JOnAS code). The core idea of our thoughts is quite the
same, I would just suggest to do a bit more modulized design to differenciate between
the POOL (instances without PK), the working memory (IN USE i!
nstances) and the "real
(instances buffered for later reuse). The working memory can be increased and
decreased per need, POOL and CACHE are only growing up to the defines size of POOLMAX
and CACHEMAX.
> 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.
So in my proposed implementation above, I would suggest to fill up POOL with that
instances that are not more needed, e. g. CACHE drops or workspace drops. For I would
implement CACHE, POOL and WORKSPACE not as functionality of Container, but of
self-managed classes that are used by Container, I do not have to worry about when to
do what in Container, but only to implement the path of pushs and drops of Cache, Pool
and Workspace. This is easy to do if the Container is not thought of one monolitic
memory that flags every entity with it's current state (cached, pooled, in use) but to
really separate them in different collections or specialized systems (like my cache
would be). The also eleminates some flag information in every bean (I think, not
thoght to the end), what may lead to less memory usage for state administration
(again, I do not know how JOnAS is at the moment, but this is what I think it would be
best from a modular and flexible view).
> 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.
So do I, but what I also want to do is a modular design, since I think that a modular
design on a basis of workspace, cache and pool will help to make JOnAS extremely
stable and easy to understand. I think this will not prevent users from getting deep
inside the code but it will support this. From my point of view it is not a question
of open source or not but of the real targets of the code design. Modularity and
readability do not interfere with performance, they support it (that's what I
encountered in all my projects). So maybe we want to do the same, but since I do not
know JOnAS code well, we talk of the same thing in different pictures?
> 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...
I'll sure look at this code since I want to understand what goes on there at the
moment and what we're actually talking about to change. The problem is that I have not
much time at the moment, and for the discussion is NOW and not when I have time, I try
to discuss without having looked at this. I apologize for this, and I will look at the
code in the next days.
> 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.
Well, who can say that he knows all impact of his doing before having it done? So am
I. But I gathered some knowledge in server design (performance, modularity, stability
etc.) in the past by reading some books about that and writing some servers before
(and writing one now, as based on beans, that's why I'm using JOnAS), and I try to
contribute this knowledge into JOnAS to make it even better. This does not mean that
JOnAS is not good, oh no, it's very good, but I see that there are some points where I
think it's design is not quite straightforward or "strange" in some kind (or even I
did not understand it, and so it just looks strange to me), and so I'll try to help
either make it straighforward or "unstrange", or to understand it - by asking you
silly questions and all that ;-).
> Thanks a lot for your interest in all this.
Thanks for you explaining all that to me. :-)
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".
