You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Øystein Grøvlen <Oy...@Sun.COM> on 2006/06/01 09:24:18 UTC
Re: JMX Extensions to Derby
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.
--
Øystein
Re: JMX Extensions to Derby
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
> >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
JMX.
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
Re: JMX Extensions to Derby
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
> >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
JMX.
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
Re: JMX Extensions to Derby
Posted by Craig L Russell <Cr...@Sun.COM>.
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: JMX Extensions to Derby
Posted by Craig L Russell <Cr...@Sun.COM>.
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: JMX Extensions to Derby
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> Ø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.
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: JMX Extensions to Derby
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> Ø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.
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway