Thread: Shutdown hook imp
I've attached a zip of diffs for the jdbc drivers to implement the shutdown hook. Someone who knows ant has to modify what I did so it only builds in jdk 1.3+ I wasn't able to build this and check if it works (something about the way things are in the cvs tree snapshot I was working out of) but the java files are free of syntax errors. -- Joseph Shraibman jks@selectacast.net Increase signal to noise ratio. http://www.targabot.com
Attachment
I don't think this patch is a good idea because: a) its only purpose is to supress warning messages in the server log when the client isn't coded properly (i.e. the client application should be closing connections gracefully/explicitly before calling exit()). b) The costs of this patch are great IMHO: 1) increased complexity by having a JDK1.3 specific build 2) increased support costs (why I am getting error XXX when I run under JRUN?) (I have already seen more emails to the list about having problems with this feature than I have ever saw about the warning messages it supresses). 3) Increased complexity for users needing to run under JRUN (and possibly other JSEE servers) because it requires editing the security manager settings to allow the JDBC driver to do this privileged operation. 4) Possibly incourages a security hole if the user does 3 above incorrectly and simply disables the security check, instead of selectively disabling it for just the JDBC driver. I see the costs far outweighing the benefits in this case. thanks, --Barry Joseph Shraibman wrote: > I've attached a zip of diffs for the jdbc drivers to implement the > shutdown hook. Someone who knows ant has to modify what I did so it > only builds in jdk 1.3+ > > I wasn't able to build this and check if it works (something about the > way things are in the cvs tree snapshot I was working out of) but the > java files are free of syntax errors. > > > > ------------------------------------------------------------------------ > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > > jdbc_shutdown_hook_diffs.zip > > Content-Type: > > application/x-zip-compressed > Content-Encoding: > > base64 > > > ------------------------------------------------------------------------ > Part 1.3 > > Content-Type: > > text/plain > Content-Encoding: > > binary > >
Barry Lind wrote: > > I don't think this patch is a good idea because: > > a) its only purpose is to supress warning messages in the server log > when the client isn't coded properly (i.e. the client application should > be closing connections gracefully/explicitly before calling exit()). For some people (like me) it isn't that simple to close the connection objects because of the asyncronous nature of their applications. > > b) The costs of this patch are great IMHO: > 1) increased complexity by having a JDK1.3 specific build We could just catch the NoSuchMethodError so when it is run on a jdk < 1.3 there will be no problem. > 2) increased support costs (why I am getting error XXX when I run > under JRUN?) (I have already seen more emails to the list about having > problems with this feature than I have ever saw about the warning > messages it supresses). Could be solved by documentation. > 3) Increased complexity for users needing to run under JRUN (and > possibly other JSEE servers) because it requires editing the security > manager settings to allow the JDBC driver to do this privileged operation. I posted the code for the policy file before. If people use that there won't be any problems. Even better if the distributed jar files were signed we could have policy file entries that would just grant the permission for code that was signed by postgres. -- Joseph Shraibman jks@selectacast.net Increase signal to noise ratio. http://www.targabot.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10-Jul-2001 Joseph Shraibman wrote: > Barry Lind wrote: >> a) its only purpose is to supress warning messages in the server log >> when the client isn't coded properly (i.e. the client application should >> be closing connections gracefully/explicitly before calling exit()). > > For some people (like me) it isn't that simple to close the connection > objects because of the asyncronous nature of their applications. Well... also, if someone is using PoolMan to pool connections, there isn't a 'close' connections anyways... it just puts existing connections into the pool. However, this is the responsibility of the parent application that is using the JDBC connections. See below... >> 3) Increased complexity for users needing to run under JRUN (and >> possibly other JSEE servers) because it requires editing the security >> manager settings to allow the JDBC driver to do this privileged operation. > > I posted the code for the policy file before. If people use that there > won't be any problems. > Even better if the distributed jar files were signed we could have > policy file entries that would just grant the permission for code that > was signed by postgres. No. Signed jar files isn't valid if people produce their own jar files from the src code. (Via cvs or a tar'd release) They would have to sign it themselves, versus having 'PostgreSQL' sign it. Otherwise, we'd have to ship a full jar file, rather than have people create their own. I feel that the shutdown hook is not something that should be in the JDBC driver itself, but in the parent application. In other words, the parent application that is using the JDBC driver should be aware of its own context, and stop the JDBC driver as needed, rather than assume that the JDBC driver is given the ability to shutdown itself. For example, if this was a JMX controlled app, one can stop() the server, which may require the JDBC connections to be closed. This would occur before the actual shutdown command. A given JMX controlled server may be stop() and start() many times while the JVM is running. The JMX hook for the application should contol the 'fate' of the JDBC connections. In short, to me, the JDBC connections should be minimal, efficent and not to add intelligence in the JDBC Driver to assume their operating environments. Virtually, Ned Wolpert <ned.wolpert@knowledgenet.com> D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7S2PbiysnOdCML0URAvNfAJ9cMpPTd8xSt4quL67bkTV3OShC1wCfTbbm RgztLP5Kn/raf0Qn52xsfMQ= =J7qE -----END PGP SIGNATURE-----