[Cubicweb] Persistent sessions: a status report

aurélien campéas aurelien.campeas at gmail.com
Wed May 14 23:18:33 CEST 2014

2014-05-14 22:11 GMT+02:00 Sylvain Thénault <sylvain.thenault at logilab.fr>:

> 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.

Why ?

> IMO we should have an api flexible enough to allow session storage
> wherever you

There are already a wealth of APIs concerning sessions, and I do not plan
to add more.
Quite a bit the opposite in practice (dont worry, I removed just a little

> want (memory, file, database, redis/memcached, whatever), but by default it

Firstly I introduce the persistent session base functionnality.
Secondly I provide a simple cache API with several well-polished backends
for in-memory, memcached, redis, whatnot).

> should be as simple as possible

Simple it is :)

> and so in memory,

This does not follow.

> 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).

Impossible to what ? I don't understand.

> > 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

I agree in general, but there is no dogma, is there ?

> existing tool such as celery for this? We could even let some simple tasks
> such

I have had a look at celery, and while it looks like the  taskly package to
for advanced stuff, it doesnt seem yet to play well with zmq and tends to
bring rabbitmq or sqlalchemy or redis or whatever...

The worker cube thing is a bit simple and brutal, it won't be everything to
but I believe it works and can be made fit in no time.

I definitely think celery would find a place in a cube though.

as sessions cleaning be executed by a tool such as cron.

We should strive to minimize the amount of sysadmin work for developpers,
real sysadmins and Coporate IT organisations people.

The thing must work out-of-the box.

> There would be a litle
> more sysadmin to do, but less complexity in the instance configuration and
> overall more flexible/understandable things.

I can't see how.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubicweb.org/pipermail/cubicweb/attachments/20140514/0277c968/attachment-0165.html>

More information about the Cubicweb mailing list