Ok, this use case is somewhat similar to ours... in that it doesn't require pyramid at all. We use sqlalchemy, but zodb shouldn't be much different.
We have 2 packages: * `myapp_pyramid` * `myapp_celery` `myapp_pyramid` will import `myapp_celery` to call it's `@task` decorated functions. these functions are just a workhorse. `myapp_celery` is also invoked as a worker daemon. it imports `myapp_pyramid`, but only to use the models and some library utilities. (in a more perfect world, the models would be in a third package). each celery `@task` starts/manages it's own transaction and database connection. it doesn't run any pyramid code, and isn't bound to a request or anything like that. quick sidenote, if you think there is a memory leak -- are you running debugtoolbar? that stashes the requests, so the process will keep growing and it will look like a memory leak... but it's really a conscious decision to keep the memory. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
