Miro, well, maybe you are right. I thought it to be easier to implement and easier to administrate, since you do not have to tell JOnAS every single table: What if you have a database with 10.000 tables? Do you really want to give JOnAS a list of 5.000 exclusive ones? Also I think this could lead to a runtime problem, if you have to look at a list with 5.000 entries at every single access (but this will be an implementation problem; maybe we can avoid this by loading different classes at JOnAS boot). But what I still not understand is, what kind of tables you are using. I mean, is that a system where only JOnAS writes into that exclusive tables and another process only reads that data? If not, this would mean that you have tables that JOnAS not only has exclusive write access, but also exclusive read access, and this makes no sense to have it in a shared database. Or what is the reason why you have this exclusive tables in the shared database? If you can explain to me why it makes sense to have exclusive tables in a shared database, please be so kind, maybe there is a case that I did not imagine yet. I do not know if connection pooling is a problem, since I did not benchmark it. Would it lead to a problem to have two different pools? I just read a good book that talked about some performance myths, and they provided an evidence that in some cases a per ressource pool is faster than a common pool. So before we have an evidence of truth, why should we assume that two pools instead of one would lead to worse performance? Thank you for your comments Markus -------- Original Message -------- Subject: RE: Re-2: tuning jonas for performances (20-Aug-2001 20:30) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] > Well Markus, this is little out of scope of this discussion but we here > have > exactly the situation you are describing, plenty of tables, some tables are > shared and some tables are exclusive. All these tables reside inside of one > database. > I think it is very unintuitive to declare two resource desriptors pointing > to the same database one as shared and one as not. What impact would that > be > on a connection pool as well? The work which will need to be done is from > the developer standpoint the same; you have to setup correctly the > deployment descriptor of concrete bean to say which resource descriptor > (database) to use/vs if the bean is shared or not. At least for me it is > more intuitive to think in a sense that this data object(=database table) > is > shared or not. Just my 2c 8-) > > Miro Halas > > -----Original Message----- > From: Markus Karg [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 20, 2001 1:20 PM > To: Halas, Miroslav; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Re-2: tuning jonas for performances > > Miro, > > I think it is not necessary to have the shared flag on a per table basis, > but it would be enough to have it on a per database basis: > > What cases do you have in mind where you want to have one database with > hundred tables shared, and hundred tables exclusive to JOnAS? I mean, if > JOnAS needs tables for it's own, why not building a new database only for > JOnAS? This is not needed to be physically a new database, but it would > enough to have a second database.properties file for the same physical > database. I cannot imagine a situation where this would not work. What > sense > would it make to incorporate tables to a shared database that are only seen > by JOnAS other than this? So, since that exclusive tables build their own > domain, they build a new database, even when they are physically in an > existing (shared) database. > > From this point of view, I suggest the following. > > 1) Function: The new flag tells JOnAS whether a database resource is shared, > > that means accessed by other systems than JOnAS, or not, that means, > exclusive. If it is shared, JOnAS does not cache, since it would give no > beneft; at every transaction start, JOnAS reads the required rows out of > the > resource for new. If it is not shared, JOnAS does caching; since no other > system can manipulate the data, JOnAS does not need to re-read data at the > transaction start and so it can work out of the cache. > 2) Location: For the database administrator is the onlyone that knows if a > ressource is accessed exclusively, and for he already has to provide a > jonas-specific ressource descriptor (db.properties), I think the best place > to that flag would be db.properties. > 3) Name: I would suggest, in analogy to the other database properties, to > have it named database.shared. > 4) Values: I would suggest to have the values 0 for > false/exclusive/nonshared and 1 for true/non-exclusive/shared. > 5) Default: For not changing JOnAS' behaviour when updating to a new > release, the default for not given property should be 1, what means, the > ressource is shared. Only that people that know exactly that the ressource > is exclusive, have to do something then. > > > ----- Original Message ----- > From: "Halas, Miroslav" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Monday, August 20, 2001 6:03 PM > Subject: RE: Re-2: tuning jonas for performances > > > > Just a little note, we would probably want to do the share flag and cache > > handling on a bean per bean instance, since some database tables can be > > shared and some not at all even within one application. > > > > Miro Halas > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Monday, August 20, 2001 3:10 AM > > To: [EMAIL PROTECTED] > > Subject: Re-2: tuning jonas for performances > > > To: [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] 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".
