You know native sessions don't support concurrency? Which is one of the reasons no native session driver was ever created. It brings your applications to a halt.
Having said that, all session drivers contain native session emulation, so your session data should be available in $_SESSION, and updates to it are written back to your session store of choice.
The problem with native sessions is that PHP keeps the session file open with an exclusive lock. Which means you can not do anything concurrently, all processes will need to wait until the lock is released.
This may not be an issue in simple web application, but is completely breaks anything ajax...
Ok and this problem does not occur when using fuelphp file sessions? I really would like to use redis, but I am not a fan of the non-native approach of fuelphp in the redis class... Would be nice if the redis class uses the native extension (php_pecl_redis) if installed and else the current one...
No, all Fuel drivers supports concurrency. Note that the downside of it is that they are not thread-safe, so you need to take that into account.
The Redis PECL extension is an optional extension, so we can not expect it to be installed. Which is why Fuel still has a software solution (Redis_Db) which is used by Session and Cache, because they can not depend on an external solution.
If the extension is loaded, the Redis class will be suppied from the extension. If not, Redis_Db is aliases to Redis by the framework.
Our Redis_Db class is a fork of Redisent (http://jdp.github.io/redisent/), which is available as a composer package. So there is no backporting needed.
Oooh ok I see... thanks.. So in Fuelphp v1 I can just use Redis as my session handler and when I have the pecl extension installed it will automatically use that...?
Correct. It's a PHP only replacement, because not Fuel itself can not have external dependencies, and because in some environments, users are not able to install PECL extensions by themselfs.
Don't forget, the PECL extension didn't exist until 2013-04-29, which is the reason we used a Redisent fork in the first place.
Ok, but would be nice if the Redis driver would detect it automatically if the pecl extension is installed... I found this nice library https://github.com/colinmollenhour/credis
If the PECL extension is detected, the Redis class will be the PECL one, and the internal class can be accessed using Redis_Db. If the PECL extension is not present, Redis_Db is aliased to Redis.
It would probably be possible to have some autodetection in Redis_Db and switch to the PECL extension, but that would require quite a bit of work to make sure there will be no backward compatibility issues.
This is effort we don't want to put into v1 anymore, but if you feel it's useful, by all means send in a PR. ;-)
Ah, you mean that. Yes, internally we have to. Because we need to support Redis for cache even if the PECL extension isn't present.
As I said, the API is different, so the only way to solve that is to have a single class with a unified API, which uses Redis if present, and Redisent if not. And at the moment we can't be bothered to make that for v1 anymore, AND at the same time maintain backward compatbility.
Donate
