Verify: JVM crash on parallel MSSQL connections (legacy #158)

[HenryNebula]

Verification of Legacy Issue baztian/jaydebeapi#158

Legacy bug: JVM crashes with SIGSEGV when multiple threads call connect() simultaneously. The race condition occurs between jpype.isJVMStarted() check and jpype.startJVM() call — two threads can both see JVM as not started and both attempt to start it.

Root cause: No thread-safety mechanism around JVM startup in _jdbc_connect_jpype(). The check-then-act pattern (if not isJVMStarted(): startJVM()) is not atomic.

Expected in jaydebeapiarrow: Add a threading lock around JVM startup to prevent concurrent startJVM() calls. Document that parallel connections are safe.

Legacy Reference

baztian/jaydebeapi#158

[HenryNebula]

Triage fix: #92

[Thrameos]

Starting jpype from anything other that the main thread after all packages have declared their classpath intent is unfortunately not supported. If was one of the misfeatures of jaybedeapi that it attempts to automatically start the jvm. The issue being that if one random package starts the jvm with it class path then every other package is stuck with suboptimal settings. And because services such as db cannot be dynamic loaded it presents an issue to all.

Unfortunately that means the best solution is always to have the main program collect the classpath, module path and jvm arguments before and start before importing jpype using packages. Packages should then check jvm start and give import error if the jvm. Is not operating. If it is started without the required class that should also be an import error.

It is the autostart antipattern that has haunted me for years. Our start point has changed many times as java has improved but autostarts present randomly resulting in issues being sent to jpype.

I wish there was a better way.