|
From: Bill H. <bi...@lo...> - 2003-02-04 12:21:56
|
Hi all, There has been a lot of activity on bug 673073 recently. It's all to do with finalization of the house keeper and prototyper threads when the application ends. This is the transcript: --- Date: 2003-01-23 13:41 Sender: trex Logged In: YES user_id=44856 First I must to say that the implementation of this pool is very robust and high quality. However I have encountered the following problems using the pool. Connection c = DriverManager.getConnection( "proxool.alias:sun.jdbc.odbc.JdbcOdbcDriver:jdbc:odbc:test","",""); md = c.getMetaData(); // using metadata // getting the connection back to the pool md.getConnection().close() //!!!!!!!!!!!!!!!!!!!!!!!!!!!!! the line above will not bring the connection up to the pool. It just closes it messing the stuff. I know it is always possible to avoid this. Finally, I have solved this problem but the listening to the real connection state would be really nice feature to have. I mean if the pool would be able to listen to the connection state and prevent it from misusinng. Andrew S. Budarevsky --- Date: 2003-01-24 10:06 Sender: billhorsman Logged In: YES user_id=91747 Andrew, Hmm, that's interesting. I see the problem, but I'm not sure of the best way to solve it. I think the only way is to proxy the DatabaseMetaData object and override the getConnection() method. The problem is that the Connection interface doesn't provide any hooks with which to listen to a connection. Hmm. I will add a FAQ describing this problem and schedule a task to fix this. Thanks for spotting such an obscure problem! Regards, Bill --- Date: 2003-01-31 17:47 Sender: billhorsman Logged In: YES user_id=91747 I have fixed this by proxying DatabaseMetaData too. It is will be in version 0.7 (due February 5th) or you can get the latest from CVS. --- Date: 2003-02-03 12:38 Sender: trex Logged In: YES user_id=44856 Hello Bill! Good work! Though I won't change my framework to apply the newest stuff for awhile I would suject that it might help to anybody else. What I wanted to tell you more is that it seems the pool does not let application quit by means of holding a running thread. But I am not sure yet. At the moment I have System.exit executed on QUIT event. Within few days I am going to check that and inform you as soon as I have something to tell you for sure. Andrew --- Date: 2003-02-03 17:06 Sender: billhorsman Logged In: YES user_id=91747 Hi Andrew, You should call ProxoolFacade.removeAllConnectionPools(delay) when you quit. This will close all connections gracefully and kill all the threads that are running. We can't think of a way of ensuring this happens automatically. The delay is the amount of time (milliseconds) that you are prepared to wait for connections to stop being active before closing them anyway. Hope this helps, Bill --- Date: 2003-02-04 10:20 Sender: trex Logged In: YES user_id=44856 Hello Bill! Thank you for the advising. It is worth. However I would say that it breaks the general concept of proxool to be a transparent driver's proxy. I know it happens due to leak of virtual machine state events. Oops... What about a finalize method? Could it be possible to close pools on finalizing? I can explain why I am so concerned of the trasparency. I am working on a framework that manages application data flows, called streams. Database is one of data sources. In my case the data source is not a driver of database or similar. It could be something very very abstract entity resembling data source behaviour. I don't think I even need to have a method closing the end point. I would prefer to rely on system-wide finalization in case of Java. It's not requirement, it's a feature. Few years ago I have implemented a pool of tcp connections resided on servlet and connected to application server. I don't remeber but it seems I closed connections by means of overriding finalize method. What would you say? Andrew. --- Date: 2003-02-04 12:14 Sender: billhorsman Logged In: YES user_id=91747 Hi Andrew, I take your point. I don't like having code call the Proxool API directly. I would really like to come up with a transparent solution to this. Actually, Proxool already overrides the finalize method, but in my experience this doesn't always get called. I suspect that calling System.exit() means that it doesn't get called. We really need to do some more investigation into this to determine exactly what circumstances cause what behaviour. I think we need to read the specs a bit more closely and then do some testing. It would be nice to know exactly what the problem is. We have not found any robust way of determining when the application has ended. Any suggestions are welcome. --- I have suggested to Andrew that he continues this discussion on this list so that we can all get involved. Regards, -- Bill Horsman Proxool http://proxool.sourceforge.net ICQ: 119577180 |