Duplicate Sessions

[lat9]

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.

[mc12345678]

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:

session.hash_bits_per_character	4	4
session.hash_function	0	0

Local first, master second.

[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 :-)

[lat9]

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);

[mc12345678]

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?

[niccol]

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.