You need the cvs version for this to work, but in general caching objects is a really bad idea because they have to be serialized and deserialized internally and all you can store are the properties anyway.  You are much better off just storing pure arrays.  Much quicker.

Edit: It doesn't work in a more complex case with a straight array; however it does work when wrapped in an ArrayIterator, for example:

<?php
$original = new ArrayIterator (array (new stdClass ()));
?>

My usage of it is caching a row (or several rows) from a remote database that needs to be looked up almost every request, but doesn't change very often.

Unserializing something from shared memory is still going to be a lot faster than fetching something from a database, surely?

I suppose, but a row from a database is not an object.  It is just data, so wrapping it inside an object which needs to be serialized and unserialized is pure overhead.  Despite that, this works fine in CVS, so no bug here.

I am experiencing the same issue trying to cache soap replies with sequences (which unfortunately are automatically wrapped in stdClass instances). I am running APC 3.0.13, which was released after you marked this bug as bogus.

At any rate, it might be a good idea to add a special handler into APC specifically for stdClass to not have to serialize.

Hi,

i'm using caching with APC and Object Arrays but i have the same problem: when i fetch an array of nulls is returned!

I'm using PHP 5.1.4 on Apache 2.2 on Windows XP PRO SP2 and APC 3.0.15-dev (Revision: 3.150, Aug 30 2007 07:08:38)

Output, using var_dump, is:
array(2) { ["it_IT"]=>  NULL ["DEFAULT"]=>  NULL }

Looks like this is caused because we don't serialize anything under the zval being passed in.  ie: we'll serialize a single object but not an array of objects because we don't check each element.  

Looks like this could be resolved by moving this logic out of apc_cache_store_zval() to a lower level....  

Gopal: any preferences on how to solve this taking into consideration the changes you'd like to make to this code in the near future?  Seems like moving this lower could make things messy.  I could make a patch but I don't want to make things worse.

Already working on it ... for a month or so now.

http://t3.dotgnu.info/blog/2007/Aug/11/

And it's taking its own sweet time to come together (and 3.0.15 not being out of the gate isn't helping at all).

This bug is back.
APC 3.0.16 and 3.0.17-dev is affected.

Simple Workaround 3.0.16: instead of 

apc_store($key,$array)
$array = apc_fetch($key)

do something like

apc_store($key,(object) $array)
$array = (array) apc_get($key)

Fixed in CVS HEAD, please re-test

Fails also in 3.0.18 and 3.0.19.

A generic workaround is to store a serialized version of the variable:

list($key, $var) = array('key', unserialize('a:1:{i:0;O:8:"stdClass":1:{s:5:"index";i:0;}}'));

// works
apc_store($key, serialize($var));
$var2 = unserialize(apc_fetch($key));
assert($var == $var2);

// fails
apc_store($key, $var);
$var2 = apc_fetch($key);
assert($var == $var2);

Confirmed problem still exists on 3.0.19 with Freebsd 7.2

Serialize workaround got beyond the problem.

Bug still exists in latest stable version APC 3.0.19-3 and
PHP 5.3.2-1 under Ubuntu lucid (development branch).

serializing and unserializing works - but is this an acceptable workaround?

It has been 3.5 years since I submitted this, and I don't 
often use PHP 
any more so don't really care, but I wouldn't consider this 
bug closed 
if you still need to manually serialize and unserialize it.

I still get an email every now and again people who have run 
into the 
bug and confirm it still occurs.

Just came across this bug when deploying to 5.2.4.

This bug doesn't seem to exist in 5.3.2 - I wouldn't be able to say what version it was actually fixed in, but my guess is somewhere between 5.2.4 and 5.3.2.

Forgot to mention, this is working with APC 3.1.4.

Awesome, works with 3.1.4-dev is good news.

Closing.