On Jan11, 2011, at 19:41 , Heikki Linnakangas wrote:
> On 11.01.2011 20:08, Florian Pflug wrote:
>> Unfortunately, it seems that doing things this way will undermine the guarantee
>> that retrying a failed SSI transaction won't fail due to the same conflict as
>> it did originally. Consider
>>
>> T1> BEGIN TRANSACTION ISOLATION SERIALIZABLE
>> T1> SELECT * FROM T
>> T1> UPDATE T ...
>> T1> PREPARE TRANSACTION
>>
>> T2> BEGIN TRANSACTION ISOLATION SERIALIZABLE
>> T2> SELECT * FROM T
>> T2> UPDATE T ...
>> -> Serialization Error
>>
>> Retrying T2 won't help as long as T1 isn't COMMITTED.
>
> T2 should block until T1 commits.
The serialization error will occur even if T1 and T2 update *different* rows. This is
due to the SELECTs in the interleaved schedule above returning the state of T prior to
both T1 and T2. Which of course never the case for a serial schedule.
best regards,
Florian Pflug
