db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: JMX Extensions to Derby
Date Thu, 01 Jun 2006 15:53:49 GMT

On Jun 1, 2006, at 1:51 AM, Bernt M. Johnsen wrote:

>>>>>>>>>>>>> Øystein Grøvlen wrote (2006-06-01 09:24:18):
>> Sanket Sharma wrote:
>>> I would also appreciate your suggestions on features the  
>>> community would
>>> like to see being implemented as JMX extensions.
>> On the top of my head:
>> - Performancs statistics (e.g., transactions committed/aborted per  
>> second)
>> - Change dynamic properties (e.g., derby.storage.pageSize)
>> - Stop a network server (would require some kind of authorization)
>> A question:  How will JMX work in an embedded environment? Will it be
>> possible to connect from another process?  If yes, if yes that
>> introduces security issues that one today does need to address for an
>> embedded configuration.
> 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?

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

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

View raw message