The reason is incredibly simple. That value is set on sess_read().

in sess_write()

$user = sess_user_load($session);

Thus, overriding the user object, and removing session_data_present_at_load. Not sure what the goal of this property is, but should consider,
1.) instead of setting it at sess_read() set it at sess_user_load()
2.) something like this feels like a work around for performance. Feels like there should be a better way..

Comments

Scott Reynolds’s picture

even further...

if ($user->uid || !empty($value) || empty($value) && (!isset($user->session_data_present_at_load) || $user->session_data_present_at_load))

Will always evaluate to true (!empty($value) || empty($value))

I believe that was suppose to be

// If this is an authenticated user, or there is something to save in the
  // session, or this is an anonymous user who currently has nothing in the 
  // session but did have something in session storage, write it to memcache.
  // If $user->session_data_present_at_load is not set, the current user
  // was created during this request and it's safest to do a write. 
  // Cases 1b, 1d, 2a, and 2b are covered here.
if (($user->uid && !empty($value)) || ($user->uid == 0 && empty($value))

But i think im still messing it up. Maybe its not a bug, worth a second look

At the bare minimum this is equivalent

if ($user->uid  && (!isset($user->session_data_present_at_load) || $user->session_data_present_at_load))
Mark Theunissen’s picture

Both issues mentioned here are still present, a year later.

markpavlitski’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Active » Needs review
StatusFileSize
new1 KB
if ($user->uid || !empty($value) || empty($value) && (!isset($user->session_data_present_at_load) || $user->session_data_present_at_load))

This check proceeds on any of the following conditions:

  1. $user->uid is valid, i.e. the user is logged in
  2. The user is anonymous, but there is a $value to store
  3. The user is anonymous and $value is empty, but session_data_present_at_load has not been defined, so we don't know if the user had a previous value or not
  4. The user is anonymous and $value is empty, but session_data_present_at_load is TRUE, so the user did have a value which we need to remove.

Because of the way the session_data_present_at_load value is set, check 4 will never actually succeed.

We can either remove this check, or make sure $user->session_data_present_at_load is not overwritten. Note that we cannot calculate it in _memcache_session_user_load() as the session object is created and passed in by _drupal_session_write().

I suggest the latter option, since it may provide a small performance improvement for anonymous users.

Patch attached.

jeremy’s picture

Issue summary: View changes
Status: Needs review » Closed (won't fix)

Closing this out; the memcache module doesn't support sessions.