For a brief period (a day), I had BOTH CoreSessionTracking and SQLSession maintaining session information. At random times, the CoreSessionTracking would totally lose ALL session data. SQLSession did not.
Well, one out of two isn't bad. ;-)
This is CoreSessionTracking without any timeout set.
My current understanding of this problem -- it does happen to others (not just me), but is very rare. The problem is not identified, is not reproducible by any digicool tests.
To be pedantic, it's not "any digicool tests", it's "any Chris McDonough tests" (CoreSessionTracking is badly named, I should have thought before presuming I could smuggle it into the core in a reasonable amount of time ;-). But yes. I wrote several complicated test cases which fire off a bunch of reader and writer threads and do a funny dance with aborts and such, and don't see the problem. I also tried testing manually, and didn't see any of the symptoms being reported.
I do have an environment which reproduces the problem within a short time, and would be glad to run any version of CoreSessionTracking that would help identify the problem.
Thank you. I think my next step is to instrument CST with debugging statements that go to the log, and ask someone in the community who is having these problems to run it for a while and attempt to associate the debug statements with the problems. I have no ETA for the debug-instrumented version.
Currently I am running with SQLSession -- so far it has not had a single problem.
I'm glad you got something to work, I apologize for your problems with CST. - C