Release notes

Version 1.0.0

New IOPs SCIOP_MOVE and SCIOP_SHMOVE for moving stored data as complete tree from one point to another. New functions :

Move -operations helps with complex data structures, that cannot be constructed with single scache_iov -operation. With move you to construct data-containing hierarchy on temporary location and when complete, move it as a whole to shared well known location replacing possible previous structure atomically.

Added new configuration option create-on-first-use that instructs backend to initialize nonexisting sessions on their first use. With this option enabled you can scache_connect to new session identifier and directly operate on it. With this option disabled, backend reports SCERR_NO_SESSION until you first either scache_open or scache_reset it.

create-on-first-use defaults to false to preserve previous behaviours of previous releases.

As usual, this release changes wire protocol again breaking backward binary compability with previous versions. Both scached and all connecting php-extensions must be upgraded and php accelerators' (eaccelerator, apc, xcache) caches must be purged.


Besides being fundamentally broken, scache_add and scache_shadd operations had crash bug that killed backend when trying to overwrite previously existing upper path. This is fixed in version

The fix affects backend daemon (scached), that needs to be updated and restarted. The php extension is not modified and update is not required.

Version 0.99.3

New IOP SCIOP_LASTERR added to scache_iov to retrive error codes inside from bulk queries. Also initially broken IPv6 connectivity on extension is finally fixed.

Besides of these, this release contains no other bugfixes. If you are already happy without SCIOP_LASTERR and IPv6 addressing, there is no need to upgrade.

But if you decide to upgrade, protocol has changed again breaking backward compatibility with previous versions. Both scached and all connecting php-extensions must be upgraded and php accelerators' (eaccelerator, apc, xcache) caches must be purged.


Minor fix to get extension compile on PHP 5.4. No reason to upgrade from previous version.

Version 0.99.2

This version adds new IOP to scache_iov -call for detecting race conditions on multi client updates to same content. In short SCIOP_VBRK compares counter on given path and skips all following writing IOPs, if value does not equal the value given as parameter.

Other changes

This release contains no bugfixes, so if you are already happy without SCIOP_VBRK, there is no need to upgrade.

As usual, protocol has changed again breaking backward compatibility with previous versions. Both scached and php-extension must be upgraded and php accelerators' (eaccelerator, apc, xcache) caches must be purged.

Some notes

What is scache's current status? There has been some guestions about scache being beta or pre-beta or something else :

Thought its version number is below 1.0, I personally regard is as "stable enough" (currently 0.99.1 being stablest around). It is used on production environments and there has not been crash bugs since version 0.90.7. Scache will be 1.0 when there is quite nothing to add or quite nothing to do differently, but there might still be long road for that kind of perfection.

In this case the "stable enough" means that it don't crash and it does what it's expected to do, but it might have some gotchas, and it might be possible to deliberately crash it for example by dumping enough garbage to it.

Currently biggest problem is in documentation. For 90% of time, scached does what documentation says. For 9% of time it does the right thing, but documentation claims it wrong. And for last 1%, documentation says it right, but scached does it wrong. Current documentation lacks code examples that would explain philosophy and good practices to sum up newbie tutorial for new converts. I'm smoothly forced to accept the fact, that there won't be popping out any blogging volunteers to write them up and I need to do it myself.

Scached is designed to be cheap tool to overcome those race conditions surrounding multi-client operations on shared data, but current documentation does not open the case.

Another problem is upgrade. Being memory backed only, upgrading that requires restarting the backend, that unfortunately kills all session it contains. There is ways to overcome that, for example gradually transfering sessions by assinging new sessions to parallel upgraded scached by prefixing and detecting prefixed session identifiers. Anyway, scached won't ever be disk backed, but there might eventually be slight urge to dump snapshot to disk on exit for restarted scached on prepopulate itself from.

Third requirement for 1.0 is testing in various different scale environments. One lesson learned is, that people tend to use things very differently from how you planned them to be used. So there is need for even more users and feedback. Please keep sending success reports, failures, things that bother and questions to

Version 0.99.1

New features

Accumulator code is enabled. Accumulator allows referring previous values in IOP bulk requests. Usage is documented under scache_iov.

Other changes

To blow up protocol once again, key- and value length are widened to full 32 bit integers instead of packing them both to one 32 bit value field like old versions did. This protocol modification allows larger keys and values thought currently clipped in ext/php-scache-proto.h to 16384 bytes for key and 524288 bytes for value.

As we have already been familiar to, this new release is again protocol incompatible to previous releases and both scached and php extension must be upgraded.

Version 0.99.0

API changes

Bug fixes

Other changes

Known issues

Future plans

Version 0.90.7

API changes

Bug fixes

Other changes

Future plans

Version 0.90.6


API changes

Bug fixes

Version 0.90.5

API changes

Bug fixes

Other changes

Late additions, IMPORTANT!!

Protocol has changed between 0.90.4 and 0.90.5. This means that 0.90.5 scached and extension are incompatible with previous versions and you need to update both ends.

Especially if you are using some php accelerator like APC or eAccelerator, you might need to purge cached scripts to get them forcibly refreshed to changed SCIOP-numbering. For example with eAccelerator, when cached scripts are stored onto filesystem also, they survive even apache's restart and won't be automatically refreshed until their original source files change.

Either purge your opcode cache or touch every script file to get it reloaded. Otherwise scripts picked from cache use wrong SCIOP-numbers and fail like:

invalid operation: 4