SQLObject cache needs to be cleared in a multiprocess server

[kevin]

Ian Bicking wrote:

Jonathan LaCour wrote:
> Ian, should I have to do this?  Turning the cache off completely did
> *not* seem to solve the problem (?cache=0), whereas this filter did
> solve the problem.

SQLObject always keeps weak references to objects cached, so turning a
cache off will not necessarily keep all objects from being cached.
Reseting the cache at the beginning of the request is probably better
and faster.

Probably TurboGears could/should do this automatically, when
env['wsgi.multiprocess'] is true.

[jonathan-lists@…]

An update on this issue: my filter did *not* in fact solve the problem, and I am still seeing all sorts of caching issues (even with caching disabled on SQLObject) when deploying under the flup multiprocess WSGI server. I think its probably a bug in SQLObject!

[speno@…]

The SQLObject docs say that you should turn off the cache if you use transactions. Is that related to this ticket somehow?  http://sqlobject.org/SQLObject.html#transactions

[kevin]

Here's a summary of the current state from an exchange between me and Jon:

> So, to summarize the problem, when running with SQLObject in a
> multiprocess environment, you have been seeing things winding up in
> the cache and not leaving it at a request boundary no matter what you
> do.
>
> Is that correct?

That is, essentially, correct.  This issue arises when using the flup
forking WSGI server.  It seems that changes don't quite "stick"
properly.  I will make a change to an object in one request, and it
won't seem to "stick" when I make the next request (like the object
is still in the cache in a separate pre-forked process).  Its
seemingly random.  Sometimes it happens, other times it doesn't!

I'm going to target this for 0.9, but I'm not 100% sure it will make it.

[ianb@…]

svn trunk now has .expireAll() methods on classes (sqlmeta) and connections, which should be safer than the clear method.

The sqlite workaround might cause additional problems related to forking, as it creates extra connections with duplicate caches.

[ianb@…]

expireAll could probably also be backported, but has not been yet.

[kevin]

The changes made for ticket #80 should fix this as well (committed in [259]). The problem here was that objects were lingering in DBConnection caches between requests. By putting each request in a Transaction, the Transaction's cache is the only one that comes into play.

[mramm]

I'm guessing that we aren't using expireAll() even though it's been in released versions of SQLObject for a while.

We probably want to fix this in 1.x because it will allow us to fully support ModWSGI with TG1 applications.

[kskuhlman]

Switched to expireAll() in r5155