I've used many JDBC drivers from different vendors, FOSS and proprietary, and if I've learned one thing, it is that each is its own world within the universe of the DBMS it operates in.
It is impossible to write a generic tool; they all end up providing plugins for DB-specific features, sure, but those plugins invariably also account for behavioral differences between drivers. You can't even rely on all JDBC APIs to be implemented that one would imagine should be "core" to the functionality. I've seen such APIs just stubbed to throw exceptions. This is especially common for metadata-related APIs. Relying on SQL states is pretty hopeless IMO. I've had to allow custom configs in apps to try and figure out the driver and connection state from exception class names and exception message contents because you can't rely on SQL states, and if you do then you realize that different drivers use different states in similar contexts, so then you allow for customization of _that_ too, bleh. All of this is to say that it feels dangerous to remove any hook we provide. I just can't see a reliable way to detect a broken Connection unless it's a detectable network breakage (if a socket or IO exception is the root cause). The bottom line is that connections are really expensive to create, and should only be thrown away if you know for sure it's gone bad. I'd never want to throw away a connection that is fine from the server POV but the driver throws exception X because for whatever reason, is reusable, but we throw it away. HTH, Gary On Mon, Feb 12, 2024 at 2:42 PM Phil Steitz <phil.ste...@gmail.com> wrote: > > In DBCP-595, a change is suggested to force close connections when a fatal > SQL exception has occurred. As of Version 2.2 of DBCP, fatal exceptions > are tracked and the fastFailValidation property can be set to fast fail > validations when a fatal exception has occurred on a connection. This > change would obsolete that property, as it would make the pool close the > connection immediately. > > I see two pros for this change and one con. > > Pros: > 0) Bad connection is destroyed immediately > 1) Works when validation is turned off > > Con: > Incorrect SQL states returned by drivers or transient failures may cause > over-zealous purging of connections. > > I vaguely recall the "Con" as the reason why we implemented > fastFailValidation instead of direct close on these failures, but I can't > find the discussion in the archives. > > Phil --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
