Open cornerman opened 1 week ago
My understanding was that synchronized blocks were not a problem anymore, though it was during the preview phase.
Another question I have is: We obviously rely on JNI to call the sqlite3 C api and there is no way around it. So I am guessing, this will unavoidably lead to thread pinning. Does anyone know more about that?
Yes, we use JNI for everything related to sqlite.
Wanted to check the status of this driver running with Loom (https://openjdk.org/projects/loom/).
As far as I understand, jdbc can generally benefit from running on virtual threads instead of actually blocking threads. So, I thought this would be useful for this jdbc driver, but I have not found any discussion about loom or virtual threads in this repo.
There seem to be two things to look out for though, because they can lead to still blocking threads with loom. Taken from the openjdk docs on virtual threads (https://openjdk.org/jeps/425):
Doing a quick search in the repo for synchronized, I can see a few occurrences: https://github.com/search?q=repo%3Axerial%2Fsqlite-jdbc+synchronized+language%3AJava&type=code&l=Java
The question is probably, which one of the synchronized blocks or methods actually contain blocking code and whether we can change them to a ReentrantLock (as proposed).
Another question I have is: We obviously rely on JNI to call the sqlite3 C api and there is no way around it. So I am guessing, this will unavoidably lead to thread pinning. Does anyone know more about that?
Is your feature request related to a problem? Please describe.
The problem for me is currently to understand, whether using this jdbc driver with a virtual thread executor makes sense, and whether we can do things to improve support.
Describe the solution you'd like
I can see two results:
Describe alternatives you've considered
Additional context
Relevant efforts done in pgjdbc for postgres: https://github.com/pgjdbc/pgjdbc/issues/1951