[Cubicweb] Persistent sessions: a status report

Sylvain Thénault sylvain.thenault at logilab.fr
Wed May 14 22:11:47 CEST 2014

On 14 mai 13:22, Aurélien Campéas wrote:
> The first patch set replaces the in-memory sessions with an
> in-database CWSession object. The details lay in the patch set. (There
> also comes a slight simplification of the web auth stack architecture)

as said as a comment on the patch, I'm -1 on database stored session by default.
IMO we should have an api flexible enough to allow session storage wherever you
want (memory, file, database, redis/memcached, whatever), but by default it
should be as simple as possible and so in memory, with cubes to provide other
backends. Also having CWSession in the core schema makes it nearly impossible to
skip (you'll always at least have a table to store sessions in the database).

> What is to be done
> ------------------
> * baseline distributed task handling in the core
> The missing feature will be the handling of "tasks", currently
> provided on a single-instance basis, and with instances configuration
> variables.
> For instance (pun assumed), session expiration should be handled by
> such a task, but we don't want all instances to compete anarchically
> for this.
> Another one: the `vcsfile` cube should be able to schedule a periodic
> mercurial-repositories-synchronisation task, with multiple instances,
> without configuration option hacks (which are costly not only in terms
> of code complexity but also in sysadmin time), without chaos
> happening.
> What is proposed is the integration of most of the `worker` cube, plus
> some missing bits, within the core. This will provide:
> * a database-enforced serialized synchronisation device
> * a distributed task API
> The missing bits are related to how a process "worker" will be elected
> to perform a task (it could be by explicit configuration, for complex
> deployments, but a zero-configuration lightweight default should be
> provided).

I would rather go a way that remove things from cw core... Couldn't we rely on an
existing tool such as celery for this? We could even let some simple tasks such
as sessions cleaning be executed by a tool such as cron. There would be a litle
more sysadmin to do, but less complexity in the instance configuration and
overall more flexible/understandable things.

Sylvain Thénault, LOGILAB, Paris ( - Toulouse (
Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations
Développement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org

More information about the Cubicweb mailing list