db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernt M. Johnsen" <Bernt.John...@Sun.COM>
Subject Re: JMX Extensions to Derby
Date Fri, 02 Jun 2006 09:38:07 GMT
> >I suggest that the distributed services level should be optional. Only
> >the agent level and the instrumentation level should be there by
> >default. This will also comply with the current Derby architecture
> >with embedded vs. the network server.
> Let me restate to make sure I understand what you're proposing (with  
> a bit of embellishment of my own).
> The jmx services are not started automatically, and if the user only  
> uses jdbc to access Derby, jmx will not be used. If the user invokes  
> a method on a Derby-provided jmx "bootstrap" class (don't know the  
> jmx terminology here -- please help) then the jmx infrastructure  
> would be initialized and the jmx services would be available to the  
> program. The jmx services might be used to start and stop databases,  
> get statistics about whether a database was running, how much disk  
> space was being used, make a backup, restore from a backup, etc. To  
> get to the data inside the database, you would still connect to a  
> Derby database via jdbc.
> Another level of service is to make the jmx services available  
> outside the vm of the owning Derby database. This is similar to what  
> we do now when we start the network server. There might be several  
> ways to start the jmx services from the vm, including a - 
> Dorg.apache.derby.StartJMX=true command line flag or via API. The API  
> version would need permissions granted to the caller's jar file.
> Did I get it?

Kind of. I just suggested the "distributed services level" which
JMXish for the JMX "network server" (or servers, you may have several
connectors) be optional.

You go further and also want to make the "agent level" (JMXish for the
JMX service inside the same VM) to be optional, which is also a good
idea. The "bootstrap" class you refer to is probably the MBean server
(which is JMXish for the container that holds the MBeans and has the
callable JMX interface) and the MBean for Derby management. The rest
of the MBeans may be produced on demand.

Wrt. secutiry: JSR 160 defines the whole works with SASL and TLS for

Details may be found at http://java.sun.com/products/JavaManagement/
and in JSR 3 (JMX) and JSR 160 (JMX Remote API).

Bernt Marius Johnsen, Database Technology Group, 
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway

View raw message