Opened 13 years ago
Closed 11 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 , 13 years ago
| Keywords: | sql added |
|---|
comment:2 by , 13 years ago
| Keywords: | sprint added |
|---|
comment:4 by , 12 years ago
| Milestone: | 0.5.0 → 0.6.0 |
|---|
comment:5 by , 12 years ago
| Milestone: | 0.6.0 → 0.7.0 |
|---|
comment:6 by , 11 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 , 11 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 , 11 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 , 11 years ago
comment:10 by , 11 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.