Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #85 (closed defect: fixed)

Opened 12 years ago

Last modified 9 years ago

SQLObject cache needs to be cleared in a multiprocess server

Reported by: kevin Owned by: kskuhlman
Priority: normal Milestone: 1.5
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

comment:1 Changed 12 years ago by 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!

comment:2 Changed 12 years ago by 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

comment:3 Changed 12 years ago 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.

comment:4 Changed 12 years ago by 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.

comment:5 Changed 12 years ago by ianb@…

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

comment:6 Changed 12 years ago 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.

comment:7 Changed 10 years ago by mramm

  • Status changed from closed to reopened
  • Resolution fixed 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.

comment:8 Changed 10 years ago by mramm

  • Milestone changed from 0.9 to 1.0.x bugfix

comment:9 Changed 9 years ago by kskuhlman

  • Owner changed from anonymous to kskuhlman
  • Status changed from reopened to new

comment:10 Changed 9 years ago by kskuhlman

  • Status changed from new to closed
  • Resolution set to fixed
  • Milestone changed from 1.0.x bugfix to 1.5

Switched to expireAll() in r5155

Note: See TracTickets for help on using tickets.