Christophe, very thank you for that information. I think I cannot believe my eyes! All the information I ever asked for. And, hey, now there is a mailing list for architecture and community! When have this features been added to the website? I mean, I looked there several times and I'm quite sure there was nothing in this direction (and I think the "under construction" gives me right that this was not public before)... Nevertheless, seems that all goes that way I hoped! 8-) Thank you Markus -------- Original Message -------- Subject: RE: how to tune jonas for performance problems (13-Aug-2001 11:05) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] > 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". > > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] To: [EMAIL PROTECTED] [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".
