Ticket #85 (reopened defect)

Opened 3 years ago

Last modified 4 months ago

SQLObject cache needs to be cleared in a multiprocess server

Reported by: kevin Assigned to: anonymous
Priority: normal Milestone: 1.0.x bugfix
Component: TurboGears Version:
Severity: normal Keywords:
Cc:

Description

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.

Change History

11/03/05 09:09:03 changed by jonathan-lists@cleverdevil.org

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!

11/03/05 11:53:53 changed by speno@isc.upenn.edu

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

11/12/05 12:30:17 changed by kevin

  • milestone set to 0.9.

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.

11/15/05 14:07:33 changed by ianb@colorstudy.com

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.

11/15/05 14:08:06 changed by ianb@colorstudy.com

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

12/01/05 13:41:22 changed by kevin

  • status changed from new to closed.
  • resolution set to fixed.

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.

01/23/08 19:11:57 changed by mramm

  • status changed from closed to reopened.
  • resolution deleted.

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.

01/23/08 19:12:29 changed by mramm

  • milestone changed from 0.9 to 1.0.x bugfix.