It turns out the root of the problem was that there's no way to
reliably know whether we need to, or even can, go around the event
loop to get the second and subsequent result sets. And previously, it
could either be the first result set or the second result set that
blocked taking locks. If one green let blocked in the second, and another blocked in the first, for the same objects we’d deadlock
Now there's only one result set, so our normal way of waiting for IO
to arrive works.
Also throws in some minor optimizations targeted to avoiding extra
trips around the event loop.
Note the incompatible stored proc change. RelStorage took steps to make sure incompatible versions don’t commit at the same time
…_detect_conflicts
It turns out the root of the problem was that there's no way to reliably know whether we need to, or even can, go around the event loop to get the second and subsequent result sets. And previously, it could either be the first result set or the second result set that blocked taking locks. If one green let blocked in the second, and another blocked in the first, for the same objects we’d deadlock
Now there's only one result set, so our normal way of waiting for IO to arrive works.
Also throws in some minor optimizations targeted to avoiding extra trips around the event loop.
Note the incompatible stored proc change. RelStorage took steps to make sure incompatible versions don’t commit at the same time