I've been reviewing code to get a better handle on the scope of
changes to support serializable transactions, in preparation for
next month's meetings with our CIO. My posts should start getting
progressively less hand-wavy. :-)
I've come to a few conclusions:
(1) The notions of having multiple serializable implementations
(SSI, S2PL, OCC) which can be mapped as a configuration option is
really not worth it. The cases where S2PL or OCC beat SSI are too
narrow to be worth the effort, and the pluggable approach seems like
it would be much more invasive and destabilizing than just picking
one and doing it more directly.
(2) If we're going with SSI, it appears that it would be a very
good idea to define a third lock method (SIREAD_LOCKMETHOD perhaps)
for the SIREAD locks. For one thing, that could keep them out of
the way of normal conflict detection (they don't conflict with
anything, per se) and out of the way of deadlock detection,
including rearrangement of waiting transactions. For another, they
have a different life-cycle -- they must stick around (along with
some minimal transaction information) until all transactions with a
snapshot prior to their commit have completed. That seems cleaner
and easier with a separate lock method.
Thoughts?
-Kevin