Well... the solution really is to use Flask context... Instead of:
def receive_some_request(args): session = Session(some_engine) # "connect" to the database (in reality, pulls a connection from a pool as soon as the Session is used to emit SQL) try: .. do things with session ... session.commit() # if you have data to commit finally: session.close() # close what was opened above. It just needs: def receive_some_request(args): with app.app_context() .. do things with session ... And it manages the session on the background, like it does for a web request. Problem solved. Thanks a lot for the help. On Sat, Jan 26, 2013 at 11:16 AM, Pedro Werneck <pjwern...@gmail.com> wrote: > > hmm, is that because your model objects themselves are controlling the >> scope of the transaction ? That's another pattern I don't really >> recommend... >> >> > As I mentioned, I'm using Flask-SQLAlchemy, where I have a global db > instance of the SQLAlchemy class, which holds the engine, current session, > session factory, etc. > > All models have high-level methods for save, delete, revert, etc, which > use the global db.session. This isn't an issue for the web part of the > application, because Flask creates a new session for each request context, > but the workers are outside the request context and the tasks use the > db.session directly, either through the models or by themselves. The > session created by Flask on the request is a subclass of the scoped session > with some signal handling extras. > > So, your solution works, but to implement that without changing > everything, I have to replicate whatever the high-level methods do using > that local session created when the task is called. I think it might be > possible to create a request context on each task call, so everyone will > have a fresh session on the global db.session, as if it were a web request, > but I'll have to go into Flask internals to figure how to do that. > > >> >> Would this all be solved if I just use READ COMMITTED transaction >> isolation? >> >> >> maybe? If the problem is really just exactly those rows needing to be >> visible. But the long running "dormant" transaction thing is still kind of >> an antipattern that will generally have negative effects. >> > > > Well... I do realize that, but unfortunately it's an application with many > bad design decisions, but it has to work somehow until we can afford fixing > everything. > > > > Thanks a lot! > > --- > Pedro Werneck > -- --- Pedro Werneck -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.