Hi Markus,
I don't think it is a defect in the mail server, but there
are many other projects that impact on JOnAS design (such
as JONATHAN, JORAM, Enhydra Database manager)
You will find number of objectweb working groups that impact
jonas design at
http://www.objectweb.org/archi/workinggroups.htm
hope this helps,
Christophe
Christophe Ney - mailto:[EMAIL PROTECTED]
Enhydra Project - http://www.enhydra.org
Lutris Technologies - http://www.lutris.com
>-----Original Message-----
>From: Markus Karg [mailto:[EMAIL PROTECTED]]
>Sent: Friday, August 10, 2001 8:19 PM
>To: Christophe Ney
>Cc: [EMAIL PROTECTED]
>Subject: Re: how to tune jonas for performance problems
>
>
>Christophe,
>
>maybe then there is a defect in the mailing list server!
>
>I have ordered all jonas mailing list. Enhydra? As I know,
>this is a project
>that USES JOnAS, so of what interest should it be for me as
>only interested
>in JOnAS? And what kind of meetings? I am listening to the the
>JOnAS mailing
>lists for nine months now, but I never saw an invitation to a
>meeting. Could
>it be that there is much clearing outside the JOnAS mailing
>lists, e. g.
>that things are talked on other objectweb lists and that this
>is not pointed
>out clearly on the objectweb homepage?
>
>If you know of that special mailing lists of information
>sources, I would
>really please you to post a list of all sources that you are
>using, since I
>am very interested in a closer contributionship with JOnAS
>(even when I know
>that discussions with me are hard work ;-) ).
>
>Are there any working groups e. g. for deciding what to
>include into the
>next versions? I mean, who decides what to do and what not to
>do? Is there
>any kind of public process where I can contribute?
>
>Thank you in advance!
>Markus
>
>----- Original Message -----
>From: "Christophe Ney" <[EMAIL PROTECTED]>
>To: "'Markus Karg'" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Friday, August 10, 2001 5:29 PM
>Subject: RE: how to tune jonas for performance problems
>
>
>Markus,
>
>Thanks for those comments. Regarding the opportunity one have to
>contribute to the JOnAS, I don't follow you.
>
>As an external contributor, I have to say that this team is doing
>the best they can to promote external contributions and your feeling
>of closeness is probably mainly due to the size of the project.
>
>If you want to know about all plans, do what I do! Enroll all
>mailling lists on objectweb.org (the architecture one will give you
>a good oversight) and some on enhydra.org, attend public architecture
>meetings that are organised by objectweb.org, and spend a lot of time
>to stay up-to-date on all specs and initiatives that impact the design.
>
>Thanks,
>Christophe
>
>Christophe Ney - mailto:[EMAIL PROTECTED]
>Enhydra Project - http://www.enhydra.org
>Lutris Technologies - http://www.lutris.com
>
>>-----Original Message-----
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]]On Behalf Of Markus Karg
>>Sent: Friday, August 10, 2001 2:31 PM
>>To: Halas, Miroslav; 'Christophe Ney'
>>Cc: [EMAIL PROTECTED]
>>Subject: Re: how to tune jonas for performance problems
>>
>>
>>
>>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".
>>
>
>
>
----
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".
