Been writing code for this thing for the first time tonight. Going to go over a few things I’ve discovered.
First, although I don’t think they actually serialize the objects they store (but rather store their binary representation and skip the serializing process), apc_store will trigger an object’s __sleep method, and apc_fetch triggers it’s __wakeup.
Cached objects don’t remember their object methods so they need to have the definitions in place before they are called back - this much is documented. What I discovered through trial and error is that if an autoloader is in place that will be sufficient to reinstantiate the object.
I ended up using two apc keys for my system and here’s the write call for now
if (function_exists('apc_store')) {
apc_store('Gazelle_Start_Data',
array(
self::$settings['projectName'] => array(
'startup' => self::$settings['config']['startup'],
'constants' => self::$settings['config']['constants'],
'frameworkPath' => self::$settings['frameworkPath'],
'projectPath' => self::$settings['projectPath'],
'time' => time()
)
)
);
apc_store('Gazelle_Main_Data',
array(
self::$settings['projectName'] => array(
'loader' => self::$settings['loader'],
'dataDispatch' => self::$dataDispatcher,
'errorHandler' => self::$settings['errorHandler']
)
)
);
}
When calling the data back we pull the start data first obviously. The only data here is what the autoloader needs to be rebuilt, and a timestamp of the cache write (if the cache is ever older than the config file it is dumped automatically).
The main data has the autoloader, then the dataDispatcher. Reconstituting these pulls the whole system back up. It’s pretty cool.
My system uses a central router, if I set the cache reset flag in the get line of the url I can see the time it takes to build without cache, and then the javascript files will be built without it. The time different is noticable - .02509 without caching, down to .0088 with ( Atholon Thurban 6 core OC’ed to 3.5 GHZ ) I’m impressed and looking forward to the results when the system is put under a real load.
You could be doing this much better if you discover the Serializable interface
Just implement 2 methods: serialize() and unserialize($serialized) in you class and then add
implements Serializable in class definition
This is much better that relying onf __sleep and __wakeup
See a tiny article I wrote on that:
Also relying on autoloader is a good practive when unserializing objects
O.o Seriously?
apc_store does NOT truly serialize the object it stores, it simply holds the binary state of the object (conversely, a serialized object is a printable string).
I actually tested serializing first then packing with apc_store. It’s noticably slower.
Second, I see nothing that supports your assertion either in your post or in your article that implementing Serializable is superior in any way to __sleep and __wakeup other than the usual “I’m cool cause I use the implements keyword” snobbery. Yes, objects can be checked for the interface with the instanceof operator, but that doesn’t help much.
Third this comment:
Also relying on autoloader is a good practive when unserializing objects
makes me wonder if you even bothered to read before shooting off your response since half of my first post is discussing the process of getting the autoloader up and on its feet before trying to unpack the rest of the cache, and how I solved that problem.
[ot]How can you expect to give useful commentary on anything that you don’t read, which you clearly did not. It’s read, comprehend, post; not post, read and maybe comprehend after.
I’m off on a clear tangent here but this sort of thing is a major pet peeve of mine.[/ot]
I did read you post, I just said that I agree with you that relying on autoloader is a good practice when you expect to be unserializing the objects from cache.
If apc cache was not serializing objects and simply storing binaries, like you said, then it would not be calling __sleep and __wakeup.
I have been using memcache for a long time, so I know memcache serializes objects, I have never use APC for storing any key/value pairs, only using it to speed up loading of scripts. But it sounds strange that it does not serialize objects, I’ve never heard of storing object state in binary representation, don’t even know that that is.
Yes, implementing serializable is superior to __sleep and __wakeup, you can research the reason yourself.
I think it’s you who has the “I’m so cool” complex, you post here not because you want a response but just to show off “look ma, I’ve discovered something because I’m so smart”
After some searching the best explanation I came across of the difference is here.
http://www.codeproject.com/KB/books/prophp.aspx
The major problem is with the private keyword. This is a distinction that could easily have caught me off guard because I almost never use private access level - I find it somewhat counter to the goals of OOP to block child classes from modifying properties they inherit. There are some corner cases where it’s useful, but they are few and far between.
Also I was wrong - apc_store silently calls serialize.
I think it’s you who has the “I’m so cool” complex, you post here not because you want a response but just to show off “look ma, I’ve discovered something because I’m so smart”
Off Topic:
I’m not the one who barreled into someone else’s thread where they are talking about setting up an autoloader from cache and telling them that they should use an autoloader. 
“barreled into someone else’s thread”?
OK, so why do you post a thread if you don’t want a response? I would never post a response unless I think I can either correct some mistake with someone’s posted code or give some useful tip on how to improve it. But it seems you get offended if someone tries to give you an advice. You see, you ended up learning that Serializable is superior to __sleep and __wakeup (also the private methods access is not the only advantage as you will no doubt will discover on your own)
You also learned that apc does call serialize when storing objects in cache.
So even if you don’t thank me, at least don’t be rude to people who give you good advice. If someone gives you a bad advice, it’s also no reason to be rude.
… Yeah, I’m being an ass this morning, sorry.
More important than the Serializable interface is the Observer/Subject interfaces in that article. I had no idea those where there, but my mind is working on applications for it. Thanks for inadvertently pointing me at that. For today though I have to finish out a receipt system. I’m trying to dump code that is using an ActiveX object for printing while wondering while in the world PDF wasn’t used in the first place.