We (again) looked deeper into what is really happening; and it is yet different.
What we ran into is the following: We tried to set a session_id our self based on information in the url, which in this case resulted in calling the session connect code (where it went wrong) twice per request. In case a cookie was send; there is no problem at all. Session is handled by web2py like always (except for the fact that it's done twice). In case there is no cookie send; there is a problem. The first call to connect (web2py internal) has no session_id, so a new one is generated. The second call to connect (our plugin) has a session id so it's handled ok. In the end of the request, the session changes are written. But in our case (without cookie) the var session_new is True (and the session file is (re)opened with 'wb'). Opening with 'wb' does seem to change the file handle. The request that is handled by a differend process at the same time will now have an invallid session. This also explains the fact that reopening the session file seemed to solve the problem except for the fact that the real problem is somewhere else. I guess that using connect is something that is / should be allowed (it's in the book), this is also the way to, for example use sessions from an other application. and there the same issue could apply: in case someone uses connect to just use a session from a different application. The first connect from web2py might result in creating a new session. While the connect which is issued later by the user does result in an existing session.
