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 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".
