Jeremy Boynes wrote:
[snip]
AIUI there are two levels of configuration: system and database
* system configuration comes from system properties and
classloader resources
* database configuration overrides based on values from derby.properties
in the database directory
My investigation says there are three levels:
- System properties set through the command line or programmatically
- Database properties
- Properties set in derby.properties
What do you mean by "classloader resources?"
Investigation of the Derby 10.1 Developer's Guide under the "Derby
System" section shows a couple of things that indicate that there can
only be one Derby system per VM, regardless of the number of
classloaders. This is in conflict with what Dan had been telling me a
"system" was:
"A Derby system is a single instance of the Derby database engine and
the environment in which it runs. It consists of a system directory,
zero or more databases, and a system-wide configuration. The system
directory contains any persistent system-wide configuration parameters,
or properties, specific to that system in a properties file called
derby.properties."
So I see "instance" and "system" are being used interchangeably. Then
further on it says:
"You could potentially have two instances of a Derby system (JVM)
running on the same machine at the same time. Each instance must run in
a different JVM."
Finally, the derby.properties file for a system must be located in the
directory specified by derby.system.home system property. So again
there is no way to have more than one system configuration per VM, as
far as I can tell.
It seems to me this could be easily fixed in the following way:
- derby.properties is loaded by the classloader
- derby.system.home can be specified in derby.properties
This would allow you to have multiple Derby system instances in the same
VM, right? Is that what you meant by a "per-classloader static property
map" below?
[snip]
Two big issues come to mind:
1) use of system properties
I would like to explore ways in which these can be replaced with a
per-instance configuration mechanism where each instance can have
separate properties. This could be as simple as a per-classloader
static property map but ideally something a little more flexible
would be useful
[snip]
Well, I would love us moving to JMX. It would solve a lot of problems
around configuration for us, and it would also enable management by
nice pretty GUIs, integration into larger systems managed by JMX (e.g.
most app servers), etc.
I recognize this a change with system-wide impact which can not be
taken upon lightly. We'd also have to do it in a way that is
pluggable, JMX is not something I expect is part of J2ME...
I would like to see JMX instrumentation too but think it needs to be
layered on over the top of the component model rather than used as the
basis for it. We have MX4J available to support pre-Java5 JREs and it
may be possible to run that under a J2ME VM as well.
I agree, I wasn't arguing that JMX would replace our component model. I
had contemplated this for about 15 minutes but I quickly recognized our
component model is much richer than what JMX provides.
X>
2) common touch point in DriverManager, especially for use within
stored procedures.
I think we can do something here with a special Driver implementation
that could handle multiple engine instances which I think makes this
related to David Van Couvering's common jar discussion.
I don't understand this point, could you explain further?
The SQL standard Java binding says that a Java stored procedure can
retrieve a connection to its database by obtaining a connection to the
standard URL "jdbc:default:connection" from DriverManager. This sucks.
Especially in J2ME where you don't have a DriverManager.
Derby supports this by registering a Driver that understands that URL
and which then retrieves the Connection from a thread local. We need to
make sure this implementation still works when multiple Drivers get
registered for the same URL from different engines. It should (I think)
if the internal Driver is registered from the engine's classloader.
I have also wondered about providing an injection mechanism for stored
procedure implementations where the engine would inject a DataSource
into the class or instance that could be used instead of DriverManager
to obtain the connection. This is obviously an extension to the spec but
might be friendlier.
Using a DataSource does sound friendlier, but it is an "extension" as
you say. And one of the "prime directives" of Derby as I understand it
is to stay with the standards, so that migration to "other databases" is
possible and customers feel they aren't locked in. How would you
reconcile this?
Thanks,
David
--
Jeremy
