Opened 12 years ago
Closed 10 years ago
#658 closed enhancement (fixed)
Rollback SQLAlchemy session after each celery Task
Reported by: | joar | Owned by: | |
---|---|---|---|
Priority: | blocker | Milestone: | 0.8.0 |
Component: | programming | Keywords: | bitesized sql sprint |
Cc: | Parent Tickets: |
Description
In the WSGI app we do a "rollback" on our SQLAlchemy session after each request.
We should do this for our celeryd tasks too to prevent the session being locked after an SQLAlchemy ProgrammingError
or similar. A good place to put it might be in a Task.after_return() method of our ProcessMedia Task
implementation.
Change History (10)
comment:1 by , 12 years ago
Keywords: | sql added |
---|
comment:2 by , 12 years ago
Keywords: | sprint added |
---|
comment:4 by , 11 years ago
Milestone: | 0.5.0 → 0.6.0 |
---|
comment:5 by , 11 years ago
Milestone: | 0.6.0 → 0.7.0 |
---|
comment:6 by , 10 years ago
We're getting close to 0.7.0 so I'm moving this over one.
But in 0.8.0! We're going to get it this time. :)
comment:7 by , 10 years ago
Milestone: | 0.7.0 → 0.8.0 |
---|
Also, even though this is not going in 0.7.0, this is *really important*. Not having this happen may mean needing to restart postgres at various points, which is just Not Nice (TM).
comment:8 by , 10 years ago
Priority: | critical → blocker |
---|---|
Status: | new → accepted |
This one is affecting us, actually.
At least we have users with open transactions in their postgresql pg_stat_activity. And this is not helping in diagnosing real database problems (because we are not able to find the root cause).
So raising to blocker for 0.8.
And confirming.
comment:9 by , 10 years ago
comment:10 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
I have added the reset_after_request()
call to both on_return which only calls if we're not in eager mode and on_fail so that if we are in eager mode but it fails then we still get the reset. This has been fbb3ee5.
If you are still having this issue please re-open this.
Please consider to use
mg_globals.db.reset_after_request()
for this. So that we have a common place for those "reset the session" things.