Multiple session objects being created for the same client IP

[Yarin]

(This question stems from an issue first brought up here)

We store user sessions in the DB using the web2py_session_{app} table. Inspecting the table, we've noticed a strange pattern happening over and over again:

Many of our app actions update the session. Generally, when a user hits the app and causes a session update, a single session record associated with that client gets updated in the DB. Additionally, however, we're noticing a large number of one-time 'orphan' session records which will also be tied to the same IP, but that have created_datetime = modified_datetime, meaning they were never updated. 

These one-time session records are usually spaced a few seconds or minutes apart, as if they were being created once per request. Some days there are dozens of these records, other days there are none. Each of these session records has its own unique key.

It's happening in both remote production (LAMP) and local dev (MAMP) environments. In both environments, however, no session records exist that are older than 3/10 (Today is 4/17), so something is clearing them out.

I can't make sense of this. Ideas?

[Massimo Di Pierro]

Which web2py version?

[Anthony]

Are clients making any kind of requests that don't send cookies?

[Yarin]

2.2.1

[Yarin]

Anthony- what type of requests would those be? Are you referring to browsers with cookies disabled? For example, this is happening on my own IP, and my browser's cookies are not disabled. 

[Anthony]

I was thinking of service requests, but that shouldn't generate session entries anyway as long as the session isn't changed during the request.

Anthony

[Massimo Di Pierro]

There was a buggy version that was doing this. Could have been 2.2.1. Not sure. Please upgrade to the latest. The reason is that is was saving sessions even when data was not stored/changed. Therefore is the cookie was not returned it would start making new session files/records.

[Yarin]

10 4 Massimo I will upgrade and update you guys on what I find. I wonder also if that bug has something to do with the mysql locking issue I describe here, which first started manifesting itself in March, a few days after the first 'orphan records' began appearing...

https://groups.google.com/d/msg/web2py/iAlrv6yaHWk/m7Dr8ztcN9sJ

[Massimo Di Pierro]

It could be.