Opened 14 years ago

Closed 12 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 Elrond, 14 years ago

Keywords: sql added

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.

comment:2 by Elrond, 14 years ago

Keywords: sprint added

comment:3 by Christopher Allan Webber, 13 years ago

Milestone: 0.4.0 → 0.4.1

Moving to 0.4.1

comment:4 by Christopher Allan Webber, 13 years ago

Milestone: 0.5.0 → 0.6.0

comment:5 by Christopher Allan Webber, 13 years ago

Milestone: 0.6.0 → 0.7.0

comment:6 by Christopher Allan Webber, 12 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 Christopher Allan Webber, 12 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 Elrond, 12 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 Christopher Allan Webber, 12 years ago

See bugs #973 and #974.

Additionally, some of the open transactions have been fixed in git master, by commenting out database up-to-date checking (hence #973).

comment:10 by Jessica Tallon, 12 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.

Note: See TracTickets for help on using tickets.