Please find my responses in-line.
On Sun, 2006-08-20 at 22:42 -0700, Kedar Mhaswade wrote:
> Thank you for the update. Some more responses inline.
> >
> > 1) - the jdbc-resource and connector-resource are the elements that
> > have pool-name as an attribute and that contains the value of
> > the name of the jdbc/connector-connection-pool defined in the
> > same config. So, in effect, you are suggesting changing the
> > description of the "pool-name" attribute from this, to a list
> > names that are comma separated. Is that right?
> > Yes
> >
> > - if yes, then what are the implications of the same on the creation
> > of jdbc-resource itself? For example, will the following kind
> > of config now be seen in domain.xml:
> >
> > <resources>
> > ..
> > <jdbc-resource jndi-name="jdbc/clustered-pool" pool-name="jcp1,jcp2" .../>
> >
> > <jdbc-connection-pool name="jcp1" .../>
> > <jdbc-connection-pool name="jcp2" .../>
> >
> > </resources>
> >
> > - if yes, then this is not a change in the description alone. It gives me
> > an impression that you are using existing infrastructure to expand
> > the relationship between a resource and connection-pool. Currently, the
> > relationship is one->one and you are extending it to be one->many.
> > Is that right, or am I missing something?
> > Yes
> >
> > - this is most likely going to complicate the behavior of --cascade
> > option on
> > delete-jdbc/connector-connection-pool commands. Can you give a little
> > more thought to it? This is of course, if above is correct.
> > Thanks for pointing this out.
> > Yes, cascade option will get affected.
> > eg: With ClusteredPool. if a con.pool is deleted with --cascade,
> > we cannot delete the resource as the resource is using more than one
> > connection pool.
>
> Hmm. This also affects the dynamic reconfiguration because the logic
> now will have to change to get the side-effected changes on
> jdbc-resource creation/deletion. Currently only the associated pool
> was being sent along with resource changes. Now, it will need to
> effect other things as well.
Ok, We shall have a discussion on this.
> Is there a specific reason you are trying to use "pool-name" attribute
> for multiple pools? Can this be handled differently?
We wanted to have limited effect on DTDs.
>
>
> >
> > - Secondly, why do you need a <sun-specific-property> which is just
> > same as <property> element? Why can't we reuse <property>? After all,
> > <property> was designed to take care of vendor specific configuration
> > options.
> > Yes, however currently we are not differentiating
> > appserver-vendor-specific and EIS-specific properties.
> > This differentiation will help users to actually know the
> > appserver-vendor-specific & EIS properties.
> >
> > eg: MySQL has 100+ datasource properties. In domain.xml/ GUI,
> > it is difficult for the user to differentiate which are sun-specific &
> > EIS specific properties.
>
>
> I don't understand this. It is GUI that needs to show "pages" of
> the properties showing most significant ones before others.
> Are you saying that we should now distinguishing at the level
> of properties themselves? That's confusing.
> Why should customer care if we put <property> or
> <sun-specific-property> in domain.xml? Shouldn't tools
> do the right thing?
Eg: of a connection pool having mysql, as well sun-specific properties.
Attached (1) & (2)
1) con. pool config in domain.xml
2) con. pool properties when listed using "get" command.
(Sun specific properties are "LazyConnectionAssociation",
"LazyConnectionEnlistment", "AssociateWithThread")
a) This will separate the properties from portability perspective. User
will know that these are GlassFish specific.
b) Further, what if there is a conflict between db-vendor property and
sun-specific-property ?
c) When MySQLProperties & Proposed Sun Specific Properties are listed
within --properties, it will might lead to confusion.
MySQL Properties
MaxReconnects
ConnectTimeout
AutoReconnectForPools
ReconnectAtTxEnd
Proposed SunSpecificProperties
ConnectionCreationRetry
ConnectionCreationRetryAttempts
StatementTimeout
> I don't think we should go this path of having
> sun-specific-property.
>
> >
> >
> > 2) If the properties you want to add are sun-specific, is there any reason
> > you couldn't make them optional attributes?
> >
> > These are optional attributes.
> > <!ELEMENT jdbc-connection-pool (description?, *sun-specific-property**
> > property*)>
>
> No, she meant making them "attributes" like:
> <!ATTLIST jdbc-connection-pool sun-specific-property-name CDATA #IMPLIED
> ...
> >
We feel that sun-specific-property is a better scalable solution.
eg: With GFV2 we are adding 5 new properties which involves DTD Changes.
With GFV3 we may add few more which may again involve DTD changes.
Having them as sun-specific-property will solve this.
>
> >
> > 3) From an API (eg AMX) perspective, I strongly dislike comma-separated
> > lists of values. It forces the user to do an "all or none" whack of
> > the value eg use a String[]. It forces the AMX code to parse the
> > value to provide a decent API, which further couples the code:
> >
> > String[] getPoolNames(); <= attribute must be parsed.
> >
> > Also, we typically are lax about saying whether the following are all
> > equivalent. Are these the same, or not?
> >
> > {p1,p2,p3}
> > {p1, p2, [3}
> > {p1,p2, p3}
> > {p1,p2, p3}
> > We can assume that all of the above are same
> >
> > What about
> > {p1,,p2,p3}
> > Erroneous configuration
> >
> > I could see other configurations that allow comma separated values.
> >
> > eg:
> > bin/asadmin get --port 4848 default-config.http-service.virtual-server.server.*
> > default-config.http-service.virtual-server.server.http-listeners = http-listener-1,http-listener-2
> >
> >
> > Thanks,
> > -Jagadish
> >
> >
> >
> >
> >
> >