More Fine Grained Control for Loading Native JDBC Lib

[belugabehr]

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:

1. The cleanup routine gets run every time, even though the JDBC native lib will never be present there - this adds startup time that is variable as it depends on the number of items that happen to be at /tmp at any given time
2. Logging is not sufficient and therefore if the org.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 the lib.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.

[gotson]

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

[belugabehr]

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.

[gotson]

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.

[belugabehr]

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?

[gotson]

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.

[gotson]

To reduce the cleanup time you could use org.sqlite.tmpdir