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?

Craig

--
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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to