Open belugabehr opened 3 months ago
If it cannot be loaded, the behavior should be to fail-fast, not fall-back.
Can you explain why you would not want fallback ?
Added logging (at least DEBUG, maybe INFO) where the Native JDBC lib file is loaded from.
PR welcome
Can you explain why you would not want fallback ?
Sure! Basically, if I misconfigure my application, I would rather it fail-fast than to fall-back. I very much want it to use the static copy of the JDBC native library I have deployed alongside my app. If it falls-back, then the fact that it is misconfigured is hidden from me and everything looks like it is working as expected.
IMHO if you set both -Dorg.sqlite.lib.path
and -Dorg.sqlite.lib.name
, then we should not fallback, and disable cleanup. That would be a breaking change though.
Or we need a new option to disable cleanup, and disable fallback.
Or we need a new option to disable cleanup, and disable fallback.
Ya, as I understand the cleanup/lock-file aspect of it, it was added to workaround a windows issue. This is really the thing that has been causing me heartburn in my production environment. Maybe we can enable these features only in Windows environment, otherwise, in Linux environments, just drop the file into /tmp
, load it, delete it.
Would that be acceptable?
I feel like having a dedicated property to disable cleanup would be the way to go. It would be non-breaking, and can be opt-in.
To reduce the cleanup time you could use org.sqlite.tmpdir
Is your feature request related to a problem? Please describe. Follow-up to #1140.
For the greatest amount of deployment safety, I have configured my application to use a static copy of
sqlitejdbc.so
via-Dorg.sqlite.lib.path
that gets deployed alongside the application. There are however some issues with this approach:/tmp
at any given timeorg.sqlite.lib.path
option is misconfigured, it is not easy to identify. That is to say, if the JDBC native lib is missing, or if thelib.path
is incorrect, then it silently fails and falls-back to loading from the JAR resources (and using/tmp
) and there is no indication that this has happened.Describe the solution you'd like Make the default to load from JAR resources, but allow users to explicitly specify (e.g.,
-Dorg.sqlite.lib.location
) where the native JDBC lib should be loaded from. If it cannot be loaded, the behavior should be to fail-fast, not fall-back.Added logging (at least DEBUG, maybe INFO) where the Native JDBC lib file is loaded from.