Thanks Alex, For people who haven't seen the posts in the Open Discussion Forum, the background was that Alex proposed to develop a server monitor along the lines of similar services in other database engines. I responded that two new developments are underway:
a) better information will be available from each database through system tables b) one server will serve several database Campbell suggested the JMX, which I think is a good idea And I asked Alex about the information he wants to provide, which he has listed below. ----------------------- My response is: Some of the information that Alex has listed can be made available for each database. Some information cannot be provided because of the way Java works. For example Java doesn't provide information on the amount of memory used by an object. A third type of information can be gathered via system calls for the JVM. As the Server instance has direct access to the Database instances it is running, all information can be retrieved by direct calls to the database. I suggest we start with the framework for getting the information from the monitor. After that, we can provide any information that can be provided via direct method calls to database instances. It is actually not a good idea to plan things so that it doesn't affect our code etc. All new developments should be properly integrated, otherwise they would cause more work in the long run. The information to be provided in the extended system tables already includes all the current database and cache properties. We can easily extend that to anything that is available internally. Fred -------------------------------------- Alex wrote: Hey, I think to discuss more details about the server monitor this is a better place. Fred. Thanks for your infos. I have not looked closely to the code of hsqldb to tell you some details of what I was thinking, but may be some ideas as a design discussion. I want to write something that will affect you as less as possible. So I think the most important information are the memory usage, the last called satement and proberly some information about the database. Most of this information I can get with the JDBC calls or proberly with writing a new stored procedure which will be run from inside the JVM of the server. To fetch the statements that are used or may be the count of connected users and so on, I thought of a small patch where I can redirect the output of the server.silent output. Proberly with a Logger as Listener. You know my database is meanwhile 64MB large and the most rows are only in two tables. So to know how long a special statement needs is a good start to do some performance optimizign stuff. The first version of the monitor should only be a lean solution, so that we can extend it later easyly. In this point I stick to the ideas of XP, do what you need now and nothing more. What kind of information do you plan to provide in the extended system tables? So as answer to your questions: The monitor will need information about - the memory usage of the Server - the memory usage of one table/index - the query time for a statement - the number of connected users - the number of parallel running processes If we can, I think the best access method would be a stored procedure or a wrapper of the Server class, so that there will be no change at your code at all. The JMX discussion can be a interessting new topic for me. Why not. I've never done something with it before but I think it can't be to complicate. What do you think Alex ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
