Session storage is database makes a lot of writes operations in MySQL, it may be the first 'table' to move outside MySQL before the cache_* tables. Having several cache backends is a must but should'nt prevent usage of session storage in APC or memcached.

So, either:
- provides examples of interaction between memcache (D6) session storage and memcache (D7) backend
- add session backends support in cache_backport module

Note that this problem has been reported on several places in cache router module, but I didn't found an implementation on Cache Router. So I'm not sure there's a solution. But it seems Cache Router can hanlde caches in apc and memcached while in the same time the memcache handles session storage.

Comments

pounard’s picture

pounard
Primary language French
commented
Assigned: Unassigned » pounard

Will attempt to do a default session.inc session handling replacement that acts as a proxy to a configuration defined cache backend.

pounard’s picture

pounard
Primary language French
commented
Project: Cache Backport (D7 to D6) » Session Proxy
Version: 6.x-1.0-beta1 »
Status: Active » Needs review

Moving this issue to the new sandbox that might allow this.

Fidelix’s picture

Fidelix commented

This would be a cool addition!

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Version: » 7.x-1.0-alpha1
Issue summary: View changes
Status: Needs review » Active

Is this the right project and status for the issue?

pounard’s picture

pounard
Primary language French
commented
Status: Active » Postponed (maintainer needs more info)

Actually this is supposed to be already doable. Per configuration you can use a cache backend to store session data, this way:

$conf['session_storage_force_default'] = false;
$conf['session_storage_class'] = 'SessionProxy_Storage_Cache';
$conf['session_storage_options'] = array(
  'cache_backend' => 'SomeCacheClassProvidedBySomeModule',
);

Read the session_proxy/session.inc file at line 34 to see how the storage is being instanciated. Also you can read the session_proxy/lib/SessionProxy/Storage/Cache.php file at line 130 to see how the options array is being used to instanciate the cache backend.

Please test it and tell if you experience any problems. I have to admit I am not myself using it.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Postponed (maintainer needs more info) » Fixed

OK, cool, then I guess this is the right status :)

I'm not planning to use it myself, but wanted to try to help clean up the queue and this issue seemed like the status was likely out of date. Thanks for the update.

pounard’s picture

pounard
Primary language French
commented

Thanks a lot :)

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Anonymous’s picture

Anonymous (not verified) commented
Priority: Major » Normal
Status: Closed (fixed) » Active

Hello,

I'm reopening this because while I have sessions being stored in the cache backend (Redis in this case), since they have a different database structure to Drupal's sessions table in MySQL, some modules that are looking for that structure will fail to work using Session Proxy as a session backend/router.

For instance, the NodeJS module has a function as follows that is expecting to have the uid & sid or ssid present in the session storge:

function nodejs_auth_check_callback($auth_token) {
  $sql = "SELECT uid FROM {sessions} WHERE MD5(sid) = :auth_key OR MD5(ssid) = :auth_key";
  return db_query($sql, array(':auth_key' => $auth_token))->fetchField();
}

With Session Proxy currently, it doesn't have that information. It is using the default cache bin structure (drupal_get_schema_unprocessed('system', 'cache')). Probably a lot of other modules will cease to work with the current method, such as Session Expire & Session Limit. Would it be possible to design Session Proxy so that it mimics the structure of Drupal's MySQL session table?

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

I think it's true several modules will stop working, but it's hard to know the solution.

My sense is that we need a set of functions that will work across the database and other kinds of session backends.

Some other similar issues I was literally *just* working on:

#2294061: Remove code to Remove all sessions for a uid if password is changed
#2490050: watchdog if sessions are not in the database

pounard’s picture

pounard
Primary language French
commented

Indeed there is no actual solution to this problem. By definition session handling is meant to be pluggable and its database table *IS NOT* a public facade. This means that any module working on it is supposed to only work with core session management.

I think that every session backend will be the cause for you of the exact same problem.

The only solution for this is the following: if you need a specific feature on the session management, and use a specific backend that does not use the database, ask politely the module maintainer to add the feature, or make a patch for your usage.

This is unsolvable in a generic way by design.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Status: Active » Closed (fixed)

Yes, agreed with #11. I suggest closing this issue - fixing it will require many new issues across a variety of modules. Perhaps a meta issue in this module's queue would make sense to track them all?

Anonymous’s picture

Anonymous (not verified) commented

A meta issue would make sense. One quick question though. Why is Drupal's session table set up just the way it is, with uid, sid, ssid, hostname, timestamp, cache? Are those used by Drupal somewhere, & on the other hand are they forbidden to be used by non-core modules?

Would it be a good head start for module developers that are already digging into the MySQL sessions table (perhaps inappropriately?), but wanting to extend their modules to allow for the use of other session backends, for pluggable session backend providers simply to imitate the structure of the SQL session table (uid, sid, etc.)? It seems that's what the MongoDB module's session.inc does (just glancing at it today).

I hope this makes sense, I'm just coming out of a major flu or maybe bubonic plague & am not quite sure my sentences are as coherent as they should be (at least they somewhat resemble English looking back on them).