On 10/21/2010 11:20 AM, unordained wrote:

> 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?

Don't think about the checks as "per transaction" - transactions write
their changes directly into data pages, so the number of checks is not
relative to the number of concurrent transactions, but the amount of
data. For your example of "no more than 25 items per invoice", the
check consists of counting the items in the parent invoice - committed
and uncommitted and the cost will never go over 26 row reads because
you don't care whether the constraint is violate by a little or a lot.

But yes, you'd need to read those 26 rows each time you

> For 3 uncommitted transactions beside your own, that's already 8
> combinations to look at?

Maybe I've misunderstood you - or vice versa. The only check is
global - reading both committed and uncommitted data and reading
all uncommitted data regardless of which transaction created it.

>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.

People who call on agreed-on-ahead-of-time ordering of transactions
tend to be academic ... how many real-world problems have you seen
that can be reduced to pre-ordered transactions?

Cheers,

Ann