Responses to Kedar, Lloyd, Rebecca:
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.
- 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.
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*)>
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