• Welcome to SQLitening Support Forum. Please login.
January 27, 2022, 04:37:02 AM


Welcome to the SQLitening support forums!

slDisconnect corrected

Started by cj, November 14, 2015, 10:08:15 PM

Previous topic - Next topic


November 17, 2015, 09:06:10 PM #15 Last Edit: November 19, 2015, 01:37:09 AM by cj
SQLiteningClient.Dll in Client.Zip

Bern Ertl

Quote from: Frank W. Kelley on November 17, 2015, 07:53:19 PM
So, is this the final solution to this issue? (adding "RESET thMutex"?)

Yes.  Thanks cj for posting a compiled solution for the folks who don't have PB.  Hopefully we can get Paul's attention and he can update the master distribution for everyone.


Yes, the download is flying off the shelves  :)

Frank W. Kelley

Thanks, cj, for your work on this. It is appreciated!


Bern Ertl  thankfully made the final fix which would have taken me forever or never since I created a problem.
The thing is that I always knew something wasn't quite right when doing lots of connects/disconnects.

D. Wilson

Thanks CJ and Bern for looking into this issue. I will be torture testing this next week and let you know what I find.

Bern Ertl

November 19, 2015, 10:26:47 AM #21 Last Edit: November 19, 2015, 11:00:29 AM by Bern Ertl
Quote from: Bern Ertl on November 16, 2015, 12:22:07 PM...
But, if I'm understanding this correctly, my suggested FreeLibrary additions (and without cj's code changes) should cause the DLL to unload upon slDisconnect.  Subsequent calls to slConnect should re-load the DLL and thMutex should be initialized, so I'm not clear on why that alone didn't also solve the lock up problem.

I think I understand this now.  Most of the test programs re-connected quickly after each disconnect.  The DLL was still running for 20 seconds (thanks to the threaded function).  Looks like subsequent calls to slConnect allowed the client app to re-load the DLL before the 20 second window ended, so effectively, the FreeLibrary calls did nothing at all (ie. threaded variables were not initialized upon the next slConnect because the DLL was never truly freed/unloaded from the OS).  If the client/test app waited >20 seconds before trying to reconnect, the FreeLibrary additions (sans the real solution) would have caused the same 20 second crash I was seeing while testing earlier.


Bern came up with final solution.
This is a must fix in my opinion.  It has been well tested.


SUB SQLiteDisconnect ALIAS "SQLiteDisconnect" EXPORT
  ' Tell ImHere thread to die
  @tlpKillImHere = 1
  reset tlpKillImHere  ' Disconnect and close Tcp socket
  DoRequest %reqDisconnect, 0, 0, "", 0
  TCP CLOSE thSocket
  CloseHandle thMutex
  RESET thMutex