Opened 11 years ago

Closed 9 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, 11 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, 11 years ago

Keywords: sprint added

comment:3 by Christopher Allan Webber, 11 years ago

Milestone: 0.4.00.4.1

Moving to 0.4.1

comment:4 by Christopher Allan Webber, 11 years ago

Milestone: 0.5.00.6.0

comment:5 by Christopher Allan Webber, 10 years ago

Milestone: 0.6.00.7.0

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

Milestone: 0.7.00.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, 10 years ago

Priority: criticalblocker
Status: newaccepted

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, 10 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, 9 years ago

Resolution: fixed
Status: acceptedclosed

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.