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.


D08C2F45:  28E7 56CB 58AC C622 5A51  3C42 8B2B 2739 D08C 2F45 
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly

Reply via email to