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 <[email protected]> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
