Launchpad itself

bug watch script should not be running in serializable transaction isolation

Bug #90098 reported by Stuart Bishop
4
Affects Status Importance Assigned to Milestone
Launchpad itself
Won't Fix
High
Unassigned

Bug Description

The bug watch script occasionally gets database serialization errors and does not handle them.

There is no reason for this script to be running in this high a transaction isolation level - it should be reduced to READ COMMITTED or possibly even run in autocommit mode which also allow simplification of the script.

Revision history for this message
Stuart Bishop (stub) wrote :

wish list because the script does not die and the failed update will probably be corrected the next day's run.

Changed in launchpad:
importance: Undecided → Wishlist
status: Unconfirmed → Confirmed
Curtis Hovey (sinzui)
tags: added: tech-debt
removed: fix-it-friday
affects: launchpad-foundations → malone
Gavin Panella (allenap)
tags: added: story-reliable-bug-syncing
Changed in malone:
importance: Low → High
Revision history for this message
Gavin Panella (allenap) wrote :

checkwatches still runs with SERIALIZABLE transaction isolation. I'm not sure what the repercussions would be from switching to READ COMMITTED, but I'm wary of going to AUTOCOMMIT; for the comment syncing part especially, checkwatches does set up more complex data structures, and I would not want it to leave half-finished stuff around. Even apparently simple tasks like updating a bug task status has many side-effects, including sending email to bug subscribers.

However, since last month, transactions are now short and ring-fenced in checkwatches.

Using the helpers in lp.bugs.externalbugtracker.isolation, it's now an error for checkwatches to begin network activity when there's a transaction in progress. This means that checkwatches must be careful about transaction boundaries, see the BugWatchUpdater.transaction context manager for how that has been approached.

A side benefit of this is to make the developers much more aware of what demands are being made of the database and when. It makes it obvious where we can optimize, or need to.

I'm marking this bug as Won't Fix because the discipline the code must not exhibit seems to make it unnecessary, but I'm interested in a discussion on this if there's disagreement.

Changed in malone:
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.