Ouch. On my own box, I changed Ape to cause a ZODB transaction even when loading objects so that it would be possible to commit or abort SQL transactions started implicitly by SELECT statements. I wrote a test then made the test pass, but getting it to pass was harder than I expected, so I dug some more. It turns out that the scanning functionality also causes implicit transactions. Oops.

The scanning functionality periodically scans for changes to objects in the database. When it sees a change made outside ZODB, it causes the changed object to be removed from all ZODB caches. It scans outside the ZODB transaction model.

Okay, having written that down, it seems apparent that one way or another, the scanner has to cause the SQL transaction to commit or abort. I'll try to achieve that.