SQLite as a Session Storage

Question

I wanted to know is it a good practice to use SQLite as a main session storage or at least as a backup session storage with primary memcached?

Could you give me some pros and cons?

(I am building a MVC Framework for education purposes and was thinking of different possibilities and implemetations)

Answer 1

SQLite Pros

• faster than file based sessions
• can be distributed where file based sessions are more awkward

SQLite Cons

• requires SQLite which creates a dependency and something else to monitor
• harder to implement that native file based sessions
• large applications can quickly kill the sql table by so many read and write requests, fragmentation, index updates, etc especially with almost every page hit hitting that specific table

Even Better Solution - Memcache

Since sessions are usually accessed with every page hit it would make sense to use the fastest mechanism possible without all the overhead of a database layer while still allowing it to work in a distributed system (multiple PHP servers for example).

Use Memcache which is well tested with PHP and you can even integrate memcache sessions just by modifying a few php.ini settings or for more fine grained control (or to use other software like redis) you can create your own custom session handler.

This has different pros and cons

Memcache Pros

• Very very fast
• Scales well
• Easy to implement via PHP.INI

Memcache Cons

• Another service that has the potential to crash and requires monitoring
• Uses RAM which is usually a limited resource compaired to HDD space and also requires monitoring

Though you should be using other software that monitor both those things or write a cron job script that checks the memcache service is still running - but thats another question and answer for another day. Point is, those cons can be lessened to some degree.

Further reading on the topics covered

• Memcache sessions using PHP.INI
• Redis
• Custom PHP Session Handler

Answer 2

Sessions based on files are a bad idea, because the file will be locked if you dont close the write access to the session ( session_write_close(); ). But why should you limit yourself/theServer when you just have to use sqlite to avoid this problem?

so sqlite pro: - easy to use (change php.ini config):

session.save_handler = sqlite
session.save_path = "/path/sessions.db"

• faster to load pages (session can now work parallel)
• faster with ajax
• build in functionality

sqlite con

• slower to write to session

i would like to use apc, but then i need to implementation and i'm worried that it could end in security issues...