Duplicate Sessions

I know that this has been covered in detail before. However, I am involved in a busy store ( by which I mean tens of thousands of page views and hundreds of sales a day ). On that store we get about one or two duplicate session errors each day. Obviously, there is no problem with the majority of sessions. The store has been running on the current server for over a year.

I am just a bit puzzled about why there are this smattering of duplicate sessions being created.

PHP Version: 5.3.3 (Zend: 2.3.0)

And

Cookie Domain True
Force Cookie Use False
Check SSL Session ID False
Check User Agent False
Check IP Address False
Prevent Spider Sessions True
Recreate Session True
IP to Host Conversion Status true
Use root path for cookie path False
Add period prefix to cookie domain False

Has anybody got any ideas? And if you want any other setting then let me know.

niccol:

I know that this has been covered in detail before. However, I am involved in a busy store ( by which I mean tens of thousands of page views and hundreds of sales a day ). On that store we get about one or two duplicate session errors each day. Obviously, there is no problem with the majority of sessions. The store has been running on the current server for over a year.

I am just a bit puzzled about why there are this smattering of duplicate sessions being created.

PHP Version: 5.3.3 (Zend: 2.3.0)

And

Cookie Domain True
Force Cookie Use False
Check SSL Session ID False
Check User Agent False
Check IP Address False
Prevent Spider Sessions True
Recreate Session True
IP to Host Conversion Status true
Use root path for cookie path False
Add period prefix to cookie domain False

Has anybody got any ideas? And if you want any other setting then let me know.

In includes/configure.php, what is the setting for your cache? Database? Try none... Should go away. Did on mine. Congratulations on the activity of your store.

mc12345678:

In includes/configure.php, what is the setting for your cache? Database? Try none... Should go away. Did on mine. Congratulations on the activity of your store.

Setting to 'none' may resolve the problem, but it comes at the cost of reduced performance.

Just thought I'd mention that.

Cheers
RodG

RodG:

Setting to 'none' may resolve the problem, but it comes at the cost of reduced performance.

Just thought I'd mention that.

Cheers
RodG

I was thinking the same, "battled" this for more than a year, I finally changed the setting to none, and though I haven't run much of a thorough system response test, it does seem to respond faster now than it did... :/ if you have any other suggestions of how to deal with the "situation" I'm certainly game. (Ie, just ignore the existence of those errors, change something to match some value, etc...) I think at one time I had changed a timing value in the php.ini file and was able to reduce the periodicity of receiving them, but I also don't know at what cost.

niccol:

... Has anybody got any ideas? And if you want any other setting then let me know.

No ideas, but the length of the session ID is controlled by two php.ini values: session.hash_function and session.hash_bits_per_character. Posting those values (and your PHP version, which you did) will help to isolate the issue.

lat9:

No ideas, but the length of the session ID is controlled by two php.ini values: session.hash_function and session.hash_bits_per_character. Posting those values (and your PHP version, which you did) will help to isolate the issue.

Php version: 5.3.13
Session.hash_function = 0
Session.hash_bits_per_character = 4
Anything else need to be provided to help isolate the issue?

I don't know if there are additional settings that would help isolate, but my thinking is that if everyone that has experienced this issue would "chime in" with these settings that a pattern might develop.

I did notice that the bits_per_character was set at the "default" setting as stated in the notes of the php.ini file instead of the recommended value for production and development versions. That meaning the recommended setting for production/development was 5, while the default was 4.

Also reason I asked about additional information, was if there was any value in knowing the lengthy "code" that is "clashing".

Yes, we do use database caching. I'll try and change that in the next few days and see the result and also try and benchmark the speeds out of interest.

settings are
session.hash_bits_per_character 5 5
session.hash_function 0 0

Personally, I don't think it can be an issue with php session creation. But that is only a gut feeling. It doesn't happen often enough for that. So, then it makes me think that there is a possibility of a browser issue similar to chrome's tendency in the past to submit data twice. But I can't repeat that on any of the browsers that I test on. But maybe on some older version...

I haven't seen this on any other store but maybe the volume on this one is showing something that goes unnoticed on others I have worked on.

:-) wish it was my own store!

niccol:

Yes, we do use database caching. I'll try and change that in the next few days and see the result and also try and benchmark the speeds out of interest.

settings are
session.hash_bits_per_character 5 5
session.hash_function 0 0

Personally, I don't think it can be an issue with php session creation. But that is only a gut feeling. It doesn't happen often enough for that. So, then it makes me think that there is a possibility of a browser issue similar to chrome's tendency in the past to submit data twice. But I can't repeat that on any of the browsers that I test on. But maybe on some older version...

I haven't seen this on any other store but maybe the volume on this one is showing something that goes unnoticed on others I have worked on.

:-) wish it was my own store!

Pairs of numbers? Is that what is really present or was something mistyped when entered here?

mc12345678:

Pairs of numbers? Is that what is really present or was something mistyped when entered here?

I'd imagine that niccol was posting both the Local and Master values.

lat9:

I'd imagine that niccol was posting both the Local and Master values.

In that case, an update on my values for "consistency" would be:
[TABLE]
[TR]
[TD="class: e"]session.hash_bits_per_character
[/TD]
[TD="class: v"]4
[/TD]
[TD="class: v"]4
[/TD]
[/TR]
[TR]
[TD="class: e"]session.hash_function
[/TD]
[TD="class: v"]0[/TD]
[TD="class: v"]0[/TD]
[/TR]
[/TABLE]

Local first, master second.

Yes, not caching the database is a solution. But comes with a seemingly small cost is performance. I didn't test extensively but the change was less than a few percent.

still interested in the cause of this error though. It must come from the functions file sessions.php. In function _sess_write zen has:

    $expiry = time() + $SESS_LIFE;

    $qid = "select count(*) as total
            from " . TABLE_SESSIONS . "
            where sesskey = '" . zen_db_input($key) . "'";

    $total = $db->Execute($qid);

    if ($total->fields['total'] > 0) {
      $sql = "update " . TABLE_SESSIONS . "
              set expiry = '" . zen_db_input($expiry) . "', value = '" . zen_db_input($val) . "'
              where sesskey = '" . zen_db_input($key) . "'";

      $result = $db->Execute($sql);

    } else {
      $sql = "insert into " . TABLE_SESSIONS . "
              values ('" . zen_db_input($key) . "', '" . zen_db_input($expiry) . "', '" .
                       zen_db_input($val) . "')";

      $result = $db->Execute($sql);

    }

Seems bizarre that this error can be created.

If anyone has thoughts then I'd be interested :-)

niccol:

Yes, not caching the database is a solution. But comes with a seemingly small cost is performance. I didn't test extensively but the change was less than a few percent.

still interested in the cause of this error though. It must come from the functions file sessions.php. In function _sess_write zen has:

    $expiry = time() + $SESS_LIFE;

    $qid = "select count(*) as total
            from " . TABLE_SESSIONS . "
            where sesskey = '" . zen_db_input($key) . "'";

    $total = $db->Execute($qid);

    if ($total->fields['total'] > 0) {
      $sql = "update " . TABLE_SESSIONS . "
              set expiry = '" . zen_db_input($expiry) . "', value = '" . zen_db_input($val) . "'
              where sesskey = '" . zen_db_input($key) . "'";

      $result = $db->Execute($sql);

    } else {
      $sql = "insert into " . TABLE_SESSIONS . "
              values ('" . zen_db_input($key) . "', '" . zen_db_input($expiry) . "', '" .
                       zen_db_input($val) . "')";

      $result = $db->Execute($sql);

    }

Seems bizarre that this error can be created.

If anyone has thoughts then I'd be interested :-)

lhungil pointed out a couple of posts back that it's most likely a race condition on busy stores (the check/optional insert is not atomic). Perhaps that section could be made atomic without changing the functionality as:

 $expiry = time() + $SESS_LIFE;
 $sql = "insert IGNORE into " . TABLE_SESSIONS . "
           values ('" . zen_db_input($key) . "', '" . zen_db_input($expiry) . "', '" . zen_db_input($val) . "')";

 $db->Execute($sql);

 $sql = "update " . TABLE_SESSIONS . "
           set expiry = '" . zen_db_input($expiry) . "', value = '" . zen_db_input($val) . "'
           where sesskey = '" . zen_db_input($key) . "'";

 $result = $db->Execute($sql);

lat9:

lhungil pointed out a couple of posts back that it's most likely a race condition on busy stores (the check/optional insert is not atomic). Perhaps that section could be made atomic without changing the functionality as:

 $expiry = time() + $SESS_LIFE;
 $sql = "insert IGNORE into " . TABLE_SESSIONS . "
           values ('" . zen_db_input($key) . "', '" . zen_db_input($expiry) . "', '" . zen_db_input($val) . "')";

 $db->Execute($sql);

 $sql = "update " . TABLE_SESSIONS . "
           set expiry = '" . zen_db_input($expiry) . "', value = '" . zen_db_input($val) . "'
           where sesskey = '" . zen_db_input($key) . "'";

 $result = $db->Execute($sql);

Based on when this has been observed to occur, I would agree that it seems like a race condition that causes this. The above suggested code, would be expected to replace the section shown previously, correct? Not some sub-part of the various if this else that conditions?

Well, yes, it evidently might be created by some kind of race condition. ( Off the record I am surprised by how often this is happening if that is the case just because of the probability of it but that just means that I am surprised not that I don't think it is so)

Yes, that code might replace the existing code.

@mc Yes, it would replace the code block that I pasted in its entirety.

I may or may not give it a try. Trade off here is changing session handling code which would mean that I need to find the time to actively monitor the store after the change or living with a couple of errors a day.