-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hikari blindly overrides Connection's readOnly and autoCommit #1116
Comments
@xathien What I propose is this:
This change will be made on v2.4.x. The v2.3.x branch is in maintenance and only critical bugs will be fixed. I cannot stress how much HikariCP has changed between the v2.3 and v2.4, in terms of stability, performance, and number of issues resolved. As you are on Java 8, I strongly recommend upgrading to the v2.4.x release train. |
Thanks for the response, Brett! I'm not certain your proposed solution will quite fix the issue, though. If If |
@xathien I acknowledge that is an edge case. However, it is also unsupported. There are lots of settings that are valid to configure via the JDBC URL, but settings that directly conflict with pool controlled parameters are not among them. This conflict appears in other contexts as well. For example, |
@xathien On a final note, changing the booleans to tri-state would be a potentially breaking change to several hundred thousand existing users. It is both unknown and unknowable how many users do not set Finally, I am curious as to what your concern over the impact of |
Hey, thanks for replying. It seems doubtful I'll sway you from here, but I'll still do my best to explain my concerns. The main impetus for this bug was the fact that I set My company's internal tooling abstracts Hikari pool creation away from me, so now we need to update that in case our chosen connection pooling library ignores the driver's settings. In any case, the fact that this bug exists (albeit closed) may help someone else diagnose their issue after Googling for it. |
@xathien If it makes a difference, I can investigate logging a warning if HikariCP detects URL parameters in conflict with pool controlled properties. Given roughly half a dozen or so most used databases (MySQL/MariaDB, PostgreSQL, MS SQL Server, Oracle, ...) and likely only two or three pool parameters at issue, it seems well within possibility to implement such a warning. What do you think? |
Having a warning would definitely have saved me a few hours, and may be a preferable compromise to a breaking change. 🙂 |
It would be even more useful if there was a setting one could flip that would suppress each of these behaviors; i.e. I have the same use case as @xathien where internally we abstract connection pool configuration at a higher level (avoids need for each app to contain the same configuration logic and allows us to swap connection pools with a build classpath change). I'm adding support for HikariCP (we currently use c3p0) and this just bit me as well for HSQL databases that are read-only by default. I can add yet-another-configuration-parameter that just doesn't do anything for c3p0 (since it doesn't appear to have an analogous configuration parameter), but would prefer to just tell HikariCP not to force changing the read-only state. Btw, c3p0 provides a "connectionCustomizerClassName" configuration parameter to enable a user to customize the way that properties get set on newly-created connections. I wonder if a similar concept would be useful here, perhaps as a way to override the default behavior applied when setting up the connection. That might allow for a bit more flexibility than a bunch of booleans that try to anticipate whether to set every possible initialization parameter. EDIT: Upon further inspection of the c3p0 implementation, I'd suggest that copying what they do precisely isn't quite flexible enough; specifying the name of a class that implements the interface they want isn't actually that useful if you want to dynamically configure these properties based on some provided configuration information. It would be better if a user could provide an instance of some concrete implementation of the interface. |
@chrisribble The latest version of HikariCP, v3.0.0 at the time of this writing, does not call |
…tion setup if they differ from defaults.
…tion setup if they differ from defaults.
Environment
Have you searched the CLOSED issues already? How about checking stackoverflow?
Yes.
Bug
If
readOnly
orautoCommit
are specified via the JDBC URL, HikariCP will blindly override them when callingsetupConnection
(both inPoolUtilities
for 2.3.x andPoolBase
for 2.4.x and thedev
branch).Proposed Resolution
Hikari should only call
connection.setReadOnly
andconnection.setAutoCommit
if the setting was directly specified.The text was updated successfully, but these errors were encountered: