Halas,
thank your for your posing, but let me add some more information:
>+ From what I understand, what JOnAS really does is to pool (anonymous)
>instances not cache them. Implementing an object cache is possible as
>Philippe D says but will have big impact on the container design.
>[Halas, Miroslav] Thanks for the info, it is important for me to know
though
>that there is this opportunity because when we get to performance
>optimization phase any option will be good 8-)
>Why do you think it would have a big impact on container design? Excuse my
>naïve imagination in this case, but when an instance is returned to the
pool
>at the end of operation or transaction it contains valid state commited to
>the database and it has also associated primary key. Wouldn't be just
enough
>to modify findByPrimaryKey and other finders to check this cache if the
>object for given key doesn't already exist there before creating a new one
>and loading it with data (of course still assuming that the data source for
>this object, in jonas-XXX.xml woule be marked as NOT shared)
[Markus Karg] I also do not understand why this should have such big impact
on the container. I also see it like Miroslav. I wrote some small caches
that work either on the client or the server side. They all work the same
way: Having a key (PK) associated with a value (Bean). This is easy to do,
in just a little of 10 to 20 lines of code. Where would be the impact to do
a "bean=lookupCacheForPK(PK); if(bean!=null) return bean else {what JOnAS
does at the moment}" before triggering the finder implementation of the
bean? Also, after having called ejbStore, it would be easy to
"bean=deleteBeanFromCache(PK);putBeanIntoCache(PK,newBean)" or something
like that. And this would not interfere with distributed cache since it
could be cascaded: First look into the local cache, if not found ask the
global cache, if not found load bean from the databasse. I do not see big
problems at this point. With doing similar caching on client and server I
improved some part of our application to a delay of two seconds, whereas it
needed 35 seconds without any caching. Sure, the cache should be some kind
of more intelligent than mine, but I do not see the problem. Miroslav, maybe
we should just try out changing the source of JOnAS?
>+ Also , my main point I guess was that EJBs are designed to run in cluster
>of
>EJB servers and it seems to me that having the object cache in the
container
>does not follow the same design. That is the reason why I was suggesting
>moving
>this to the resource manager.
>[Halas, Miroslav] This is the common scenario which everybody thinks about,
>but we have very strong case for deployment scenarios when the whole system
>will exists on single laptop or desktop machine and therefore we actually
>need container which takes as much advantage as possible from the fact that
>it is not being distributed.
>I was mentioning this, because I know that Weblogic had an optimization
like
>this (the shared flag) since I believe 4.51
[Markus Karg] We also think of more likely having one fat server running a
single container than having many small servers building a cluster of
containers. And also we have the need to run the system on laptops and
desktops. But from a logical point of view, I (again) think we have to
divide into tasks. One task is, we need to have a switch where I can tell
that a specific ressource is not shared, so the system (what ever part may
have interest on that switch) can improve caching (maybe there are other
improvement factors, e.g. lower local TX levels since there cannot be
phantom rows etc.). This is the problem we talked about. The other task are
clusters. If some users need clusters, ok, then we have to support them, but
NOT on the cost of users that do not need or do not want clusters (since
clusters are bringing overhead to desktops and laptops). So clustering
should be an additional level ON TOP of the container and may not interfere
with the container-local caching. This could be done by a hierarchic cache:
If we first lookup the local cache, and after that the global cache, we just
have to write through to the global cache (maybe in a background task, or by
setting a dirty flag in the global cache). This is no JOnAS specific
problem. Every SMP system has to deal with distributed caches and there are
standard solutions.
>+ For jonas EJB2 container, there is actually an on-going project (JORM)
>that
>aims at providing a (distributed) cache of persistent objects. This
>distributed
>cache will be connected to the container via connectors. (you may
>contact [EMAIL PROTECTED] for further information on
>this).
>[Halas, Miroslav] I have heard about this, but with my limited knowledge I
>am not sure how does it solves the problem of caching actual beans compared
>to just data, because from what I see the overhead connected with
>construction of beans and loading them with data is quite big.But I will be
>interested to look into this when it comes out.
[Markus Karg] Maybe there should be more public information of the details
of what and where is done. I can remember, some weeks ago I asked where
JOnAS will go and got some core answer. Sure, JORM was told, but no one said
that there is the aim of prividing a distributed cache that is glued to
JOnAS by means of connectors. :-( How could JOnAS users contribute to JOnAS
development if current, public discussed problems interfere with non-public
plans (every minute of our discussion is wasted time and money then)? And if
it is not intended to have JOnAS users contribute, why then making it open
source? Just to let them fix bugs? O suggest (as I did some months before)
totally opening the development process and having a fine grained schedule
made public in the web. Why not using sourceforge? Why not having something
like "JOnAS Community" that votes what to do and what not? Okay, back to the
problem. As I told above the distributed cache is independent of the
container-local cache, for they will build up a hierarchic system and not
everyone is interested in clusters, since not every user needs clusters and
since the distributed cache (and the connectors, which I thought to be
invented for connecting ressources and not helper systems like caches) are
eating up some performance. So maybe JORM's distributed cache can help
performance in a clustered system, but still the local caches are needed: In
a non-clustered environment, they will be faster than distributed cache, and
in clusters environments they will build the second level cache while the
distributed cache will be the first level cache. Or is JOnAS architecture
thought to totally cutting away the container from the ressource, so that
every container talks to a global ressource management, which internally
uses the cache (I do not know how JOnAS does it at the moment, or what JOnAS
is wanted to do in future)? Well, this would lead to heavy performance
problems in environments that do not need distributed ressources (as laptops
and desktops, since they have to use IP to communicate and cannot use direct
method calls), even if it is a nice and straight design. Or am I going wrong
here?
>+ If the problem to solve is really displayed vs editable data. The
approach
>I suggested using a non XA datasource might do the job. It requires using a
>non XA driver and a non XA pool such as the (StandardPoolDataSource)
>provided
>in jonas. If the XA drivers differs from the non XA one, the 2 drivers must
>be
>loaded.As for "jConnect 5.", it should implement both XADataSource and
ConnectionPoolDataSource.
>[Halas, Miroslav] Yes I agree with you that that's one way to do it, I was
>just wondering if there is a way how to take advantage of situation when
>user is periodically display and edit the same data object (in this case
>represented by EJB bean) by just reusing the same cached copy.
I do not think that this solves the problem in common since there are a lot
of application that have to different ways (showing vs editing) accessing
THE SAME (!) data. It is not a question of how a specific ressource is
accessed, but of if a specific ressource is shared! Think of having a
tree-style browser that lets the user navigate through data. He really just
looks at the data for navigation. Then he double clicks a row to open it in
a different window, where he can edit THE SAME DATA. So I cannot change
driver. It's a problem of the deepest level ("Ressource: Is this data
shared?") and not of the highest level ("Viewer: Does user want to edit?").
We should not think of solving one specific problem but of developing a good
solution that works in either case. A flag at the ressource's DD would solve
ANY case. A local cache would support ANY environment. The XA-driver
discussion solves ONE case. The distributed cache supports any case, but
leads to performance drawbacks on single server systems, if it is not
supported by a local cache that can be accessed directly, without having to
use IP to ask the global cache running on the same machine.
Nevertheless, JOnAS is a very good product, but we should all try to discuss
more things in public, so that everyone can participate. JOnAS users are not
just users, since JOnAS is open source.
Markus
----
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".
