KohanaPHP » Kohana v2.x

The get() and set() methods of the Cache library and its related drivers should be refactored so that serialization and unserialization takes place within the drivers when necessary. In the case of the memcache driver, serialization and unserialization would never be necessary since anything other than a string or int is automatically serialized and unserialized by the native Memcache methods. (This refactoring would also fix the issue described above with passing in an array.)

Geert and I discussed this during a Bughuntday meeting (The topic was Zend Framework, but Geert and I made it our own Kohana meeting ;-) ), the previously attached patch is partially the feature-request. It allows cache back ends to do their own serializing, however it does not fix the array parameter getting of data. Since this forces some active design changes.

e.g.:

The Id's are translated from / or \\ to = to keep valid key names, so returning a associative array might be inconsistent:

<pre>
$cache->set('a/a', range(0,10));
$cache->set('b/b', range('a','z'));

var_dump( $cache->get(array('a/a','b/b')) );

// Return a-1, with the current translated id's
array(
 'a=a' => array(0,10),
 'b=b' => array('a','z')
)

// Return a-2, with the untranslated id's
array(
 'a/a' => array(0,10),
 'b/b' => array('a','z')
)

// Return n
array(
 0 => array(0,10),
 1 => array('a','z')
)
</pre>

Return A-2, would be most favorable (for obvious reasons) and doable of the original id's will remain available when returning data. However it leads to a inconsistent return value when called with a single id.

Proposal to introduce a new method e.g.: getMultiple and possibly a counter part: setMultiple rather then changing the current set and get

Memcache driver now takes care of seriliazing stuff itself, r3652.

$data = Cache::instance()->get(array('key1','key2'));

var_dump($data)

outputs:

array(2) { ["key1"]=>  string(6) "value1" ["key2"]=>  string(6) "value2" } 

I believe this already works?

Additionally, the memcache ext (note: not the memcacheD ext) does not support multi set.

There is nothing preventing a call like so being handled by the drivers supporting multi set:

Cache::instance()->set(array('key1','key2'),array('value1','value2'));

Thoughts?

Scrap that last comment.

I'm adding 2 methods to the Cache library:

get_multi(array('key1','key2','key_that_doesnt_exist');

array('key1'=>'value1','key2'=>'value2','key_that_doesnt_exist'=>NULL)

and the second method

set_multi(array('key1'=>'value1','key2'=>'value2'), $tags, $lifetime);

which returns TRUE if all items were set correctly, or FALSE if a single item fails.

Drivers are free to override these methods to take advantage of any driver specific methods for better performance than a simple foreach()

...Some benchmarks are attached, I'm not sure how accurate they are - the memcache results are too good...

I've still got to work out the details for layering a tags supporting driver over a tag un-supporting driver... It will be slow(er) if you use tags - but the same if you dont... and at least the option will be there!

I noticed a bug (?) in the root / branches / 2.4 / system / libraries / Cache.php
on line 159 in the delete_tag function, where I guess this "return $this->driver->delete($tags);" should be "return $this->driver->delete_tag($tags);"

Also, a discussion on implementing tags on memcache/xcache etc can be found here:
http://framework.zend.com/issues/browse/ZF-4253
The bottom line is that one cache location stores all tags and their related keys. This 'mastertag' should be implemented in File Cache and should never expire so that you won't lose it somehow.

we actually had something like that until a commit I made about 30 seconds ago :)

Using a single cache item to store the tags is incredibly prone to race conditions... if any 2 requests change the tags at the same time, one of them wins... but I'll read that and see if they come up with a way around it anyway ;)

That being said... the file cache driver suffers the same problem, to a lesser extent...

Well - that ZF suggestion is identical to what I just removed ;)

one of the comments suggests something slightly better... but still prone to race conditions if two requests use the same tag at the same time...

Personally - I use the memcache patch for tags support... the syntax is WOEFUL but it works...

Kiall Mac Innes wrote:

we actually had something like that until a commit I made about 30 seconds ago :)

Using a single cache item to store the tags is incredibly prone to race conditions... if any 2 requests change the tags at the same time, one of them wins... but I'll read that and see if they come up with a way around it anyway ;)

That being said... the file cache driver suffers the same problem, to a lesser extent...

The line is still the same in http://dev.kohanaphp.com/projects/kohana2/repository/revisions/4605/entry/branches/2.4/system/libraries/Cache.php? Or is it not supposed to change right away? Still noob with trac/versioning systems etc ;)

About the race condition... Could it not be solved with some exclusion flag?

The exclusion could be with something like the bakery algorithm

num[i] = 0 ; choosing[i] = False
concurrentbegin
P1 P2 P3 ... ... Pn
concurrentend

Pi: ...
choosing[i] = True // Entry: take ticket
mn = 0 // unshared variable
for (j=1 ; j <= n ; j++)
mn = max (mn , num[j] )
num[i] = mn+1
choosing[i] = False
for (j=1 ; j <= n ; j++) // Entry: Waiting for turn { while choosing[j] { }
while ( num[j] > 0 and
(num[j],j) < (num[i],i) ) { }
}
Critical section (updating cache)
num[i] = 0

The only problem being how to implement the to be shared choosing[] and num[] arrays and how to know what processnumber (i) you have... Which probably makes the race condition impossible to solve...

ah, so i was browsing an early version... Should have checked that out. Thanks for fixing :)
I will further reply about the tags problem in the other issue!