Edgewall Software
Modify

Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#4120 closed defect (fixed)

OperationalError: cannot commit transaction - SQL statements in progress

Reported by: PBruin Owned by: Christian Boos
Priority: highest Milestone: 0.10.2
Component: version control Version: 0.10
Severity: normal Keywords: tags wiki timeline
Cc: peter.bruin@…
Release Notes:
API Changes:

Description

I have noticed that I get these errors every now and then when I try to view the timeline. This seems always seems some how related to a previous commit action. This time I was unable to get past the error even with restarting my server. I only managed to get it working again when I went to browse the latest changeset via Trac. Is this a th:wiki:TagsPlugin issue?

Wiki changes event provider (TagsWikiModule) failed:

OperationalError: cannot commit transaction - SQL statements in progress

Attachments (1)

trac.log (10.1 KB ) - added by PBruin 11 years ago.
Log file

Download all attachments as: .zip

Change History (9)

comment:1 Changed 11 years ago by PBruin

I had the error again after my next commit. This time the error came from the Ticket Module. After this I disabled the tags module to be sure but it did not work. Only when I browsed the latest changeset the error would go away.

Ticket changes, Ticket details event provider (TicketModule) failed:

OperationalError: cannot commit transaction - SQL statements in progress

Changed 11 years ago by PBruin

Attachment: trac.log added

Log file

comment:2 Changed 11 years ago by PBruin

I can pretty much reproduce it. If I go to the timeline after a commit I will get an error on one of the modules changes event provider. The log I have attached show me restarting the server, checking the timeline resulting in error, going to WikiStart (you'll see some errors caused by me having disabled the tags plugin), going back to the timeline and still having an error, going to Browse Source, and then at last a successful visit to the timeline.

Wiki changes event provider (WikiModule) failed:

OperationalError: cannot commit transaction - SQL statements in progress

comment:3 Changed 11 years ago by Christian Boos

Component: timelineversion control
Owner: changed from Jonas Borgström to Christian Boos

Yes, this is a known issue… I plan to fix that in the coming days for trunk (see #2902) but it seems that this also happens on 0.10-stable, because of r3972.

For 0.10-stable, the approach suggested in #2902 won't work, of course.

Some possible solutions:

  • add a flag to get_changeset() for skipping sync()
  • in sync(), catch the OperationalError and ignore it

comment:4 Changed 11 years ago by Christian Boos

Priority: normalhighest

comment:5 Changed 11 years ago by Christian Boos

add a flag to get_changeset() for skipping sync()

Well, that would contradict the purpose of r3971, introduced to fix #3387. It's the same get_changeset() call (sourcetrunk/trac/versioncontrol/web_ui/changeset.py@4255#L676) which is concerned, so we can't say sometimes "sync", sometimes not.

in sync(), catch the OperationalError and ignore it

Probably the best compromise. I think we should only catch the commit() failure, and ignore if it fails. The tables will still "look" ok for the request currently processed, and the sync will be retried in subsequent requests, possibly in a better context (i.e. no statement in progress).

  • cache.py

     
    110110                                   (str(current_rev), path, kind, action,
    111111                                   base_path, base_rev))
    112112                current_rev = self.repos.next_rev(current_rev)
    113             self.db.commit()
     113            try:
     114                self.db.commit()
     115            except:
     116                pass
    114117            self.repos.authz = authz # restore permission checking
    115118
    116119    def get_node(self, path, rev=None):

Yet another approach would be to have a startup(tid) phase in the environment, symmetrical to the shutdown(tid). There, it would be safe to attempt a sync(), but this would introduce an additional cost for requests which would not have normally something to do with the versioncontrol subsystem…

Later, in the VcRefactoring, I'd like to do this with a dedicated thread. This would have some additional positive side-effects, like getting rid of the trac-post-commit-hook, no wait for the unfortunate user triggering a sync after a big commit, …

comment:6 Changed 11 years ago by PBruin

I think the solution with the startup(tid) would be the cleanest. This will always work and can later be re-factored to the dedicated thread. It will also solve the small problem of links to change set showing as non-existing. This is caused I guess by the post-commit-hook adding references to change sets in tickets that have not been imported by the sync.
For now I resolved my problem by creating a work-around and adding a simple perl script to my post-commit-hook. Quick but dirty…

$inet = Win32::Internet->new();
$file = $inet->FetchURL( "http://localhost/trac/browser" );

comment:7 Changed 11 years ago by Christopher Lenz

Resolution: fixed
Status: newclosed

Patch by cboos applied in [4265]. IIUC, we've solved (are are going to solve) this in a better way on trunk.

comment:8 Changed 11 years ago by Christian Boos

See also #2902 for a follow-up.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .

 
Note: See TracTickets for help on using tickets.