Hi, Apologize for the late reply.
It is a little hard to understand what I am voting on without details of what is going to be provided. Do you recommend any specific reading to be able to understand jmx and what you want to do for derby in that context.
Check out the references on the Requirements for JMX page. The following article from IBM developerworks is also a good read to gain a general understanding about JMX and its uses. http://www-128.ibm.com/developerworks/java/library/j-jmx1/ I'm also writing a small article that describes what JMX is and what it can do for Derby. It will be up on wiki in a few days. For instance derby already presents
a way to look at a list of all locks in the system, if you are just going to repackage the list into a different linear list then that is not that interesting, but if you will provide a much friendly view of the info then I would rate that high.
Nope. Not just repackaging. A console and/or a web interfaces is on the cards.
Some of the low level monitoring is hard to comment on without understanding the costs incurred by the monitoring. xact/second may be interesting but not at the cost of slowing down every xact in the system.
Agreed. I'll need a way to figure the costs and put it up on the wiki for further discussion.
I would rate creating and using a backup as 4's, it would be really nice to have a user friendly way to do this. Even better would be a user friendly way to set up a system of daily incremental using rollforward backup and weekly full backup.
What ever feature I deliver, will be through a nice GUI console or a web interface.
I would rate running recovery as 0, there is no way to run recovery other than automatically by connecting to the system. I would add compressing a table to management, probably same priority as rebuilding indexes.
Depending on when suresh is done it may be nice to add encrypting existing db to management, i believe interfaces are already checked in so early development on management should be possible.
Note taken.
Are "notifications" binary this happened events, or is info also passed. A programatic way to get the query text of executing queries may be interesting - I don't know if this is monitor or notification.
Some info will passed to give application some idea of what happened exactly. Are you referring to Query plan when you say "query text of executing queries". If yes, than that is already on list under monitoring features (Mon 19)
how about compile vs. execution time of queries.
I'll have to check the overheads involved. Will get back with stats on these issues. Thank you for your feedback!! Best Regards, Sanket Sharma
