Opened 9 years ago

Closed 7 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.

Subtickets

Change History (10)

comment:1 Changed 9 years ago by Elrond

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 Changed 9 years ago by Elrond

Keywords: sprint added

comment:3 Changed 8 years ago by Christopher Allan Webber

Milestone: 0.4.00.4.1

Moving to 0.4.1

comment:4 Changed 8 years ago by Christopher Allan Webber

Milestone: 0.5.00.6.0

comment:5 Changed 8 years ago by Christopher Allan Webber

Milestone: 0.6.00.7.0

comment:6 Changed 7 years ago by Christopher Allan Webber

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 Changed 7 years ago by Christopher Allan Webber

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 Changed 7 years ago by Elrond

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 Changed 7 years ago by Christopher Allan Webber

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 Changed 7 years ago by Jessica Tallon

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.