I believe I already posted on this at: http://sourceforge.net/tracker/index.php?func=detail&aid=523290&group_id=233 16&atid=378133
last month. This is a small part and parcel of a general reworking of the Log class, scheduled tentativley for hsqldb 1.7.1 beta. This will most likely not make it into the 1.7.0 release candidate, because there is probably not enough time to do a proper job of analyzing and rewriting the whole class before the tentative release date. There are several outstanding startup and shutdown issues, such as: http://www.geocrawler.com/mail/thread.php3?subject=%5BHsqldb-developers%5D+M ORE+The+database+is+already+in+use+by+another+process&list=11085 http://sourceforge.net/tracker/index.php?func=detail&aid=461556&group_id=233 16&atid=378133 http://sourceforge.net/forum/forum.php?thread_id=647774&forum_id=73673 and as a result, modidifcations have been made to the hsqldb distribution by various application server projects that use it as one of the default RDBMS choices (e.g. JBoss). However, none of these modifications have proved to provide a comprehensive solutuion to the multiple problems. BTW: In standalone mode, hsqldb starts only one secondary thread: the logging thread, tRunner, found in the Log class. In server mode, a listener thread and a thread handling each network connection is started in addition to the logging thread, but the connection handling threads are handled exclusively by the Server class and are totally unknown to the database engine, since the Server class acts as a decoration to the engine, rather than as a collaborator (hence some of the observed shutdown problems, such as the inability to start up a new server at the same port until all old network connections are closed at the client side, since the Server does not track the threads it creates nor the sockets they handle) Personally, I think to clean all of this stuff up, Server, Database, and Log need to be modified, in part by using daemon threads where that makes sense. However, associated clean up code must also be put in place and logic to ensure its execution occurs under a number of thread interuption or thread death situations, so it is not a simple matter of just injecting thread.setDaemon(true) into the code. My first instinct on the matter is to make the Database class implement add/removeActionListener and modify Server and any threads spawned by the engine to listen for a shutdown event and try to exit cleanly when that event is received. Basically, Server would record the sockets created for connections and would close them when a shutdown action occurs. Similarly, the logging thread would listen for such an action, interrupt, clean up, and die when such an action occurs. This goes further than simply exiting if there are no-non deamon threads still running in the VM, but still does not cover the case of a program making an unsuccessful connection attempt to a standalone url, due to bad username or password. Since jdbcConnection caches Database instances and keeps a use count, and since it does this in the wrong order (i.e. caches a new instance and updates the usage count *before* the requested connection is successfully generated), then it is possible for the JVM to stay open becuase the logging thread is still running against a cached instance whose use count can never reach zero, since no connection object is returned to the client, so no connection can be closed (the only way to lower the useage count). So, certainly, this is a case that setDaemon(true) could fix, but it does not catch the real logic error, which can additinally cause confusing errors such as receiving "the database is in use by another process" when then attempting to start an instance againt the same url from another JVM or trying to start a Server against the saqme url inside the same JVM. Hopefully, the above gives you a little demonstration of the additional considerations, and why the simple addition of setDaemon(true) will not solve all of the problems. However, there is no doubt that it will solve some of the problems, although (without the addition of some new code) possibly with some minor but undesirable side-effects, such as no attempt to flush the log buffer at exit. Cheers, Campbell ----- Original Message ----- From: "Mark D. Anderson" <[EMAIL PROTECTED]> To: "Hsqldb-Developers" <[EMAIL PROTECTED]> Sent: Wednesday, March 13, 2002 8:08 PM Subject: Re: [Hsqldb-developers] why not use Thread.setDaemon(true)? > I should add: ... if any hsqldb connections are left open at completion of main(). > If you close all your connections, then the program exits when main() completes. > > But note that this means that an uncaught exception may not exit your program, > if it throws past connection closing. > > (this is all with a local file url, not the remote case). > > I don't know how many threads hsqldb starts, nor what they do, nor whether this > is deliberate. > > > > i note that hsqldb is currently not using Thread.setDaemon(true) on its threads. > > That means that they behave like user threads, and will prevent a program from > > exiting, even after the main thread completes. > > > > _______________________________________________ > hsqldb-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/hsqldb-developers > _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
