This is very unlikely behavior, as the sessionkey is the
only way of reconnecting a calling user to a session, and
this is very heavily tested code that hasn't been touched
in a very long time.
Please check the trace of the control.stml file, which is
probably the source of any bug here--it might be ignoring
that the sessionkey is bogus, then do a TEACTION CONNECT
that due to a TEACTION RELEASE KEEPOPEN could get a
transaction in progress.
If you'd like help in diagnosing this, please compile with
trace and send us the /screensurfer/hostserver/templates.log
file to email@example.com and we can figure-out what is
To reproduce completely, compile for trace, open a
transaction then pass in the bogus sessionkey that picks-up
the prior session...