---------- Original Message -----------
From: "Ann W. Harrison" <aharrison@...>

> > I guess you're aiming instead for the on-commit checking to see uncommitted
> > stuff too? B would fail because of A's uncommitted changes, and my "globally"
> > vs. "remotely" difference goes away?
>
> Right

------- End of Original Message -------

So in that case, every check against uncommitted changes has to check for all
combinations of "self + committed" + none/each/some/all "uncommitted", with short-
circuit eval? I guess that's the saving grace: if you can guess which other
uncommitted transactions, particularly simple single transactions, would be
sufficient to cause a violation, you can avoid checking them all. Worst-case, for
N concurrent transactions besides your own, you get sum(N!/((N-k)! * k!), k=0..N)
checks to do. For 3 uncommitted transactions beside your own, that's already 8
combinations to look at? Is this where some researchers call on serializability,
particularly with an agreed-on-ahead-of-time order for transactions, to save the
day by reducing the number of checks necessary? I'm (entirely) out of my league
on that topic.

-Philip