Greg Stark <stark(at)enterprisedb(dot)com> wrote:
> On Mon, Jun 1, 2009 at 8:55 PM, Kevin Grittner
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> You can be sure you've written your transaction safely just as soon
>> as your COMMIT returns without error.
>
> I think we have different definitions of "safely". You only know
> that you got away with it *this time* when the commit returns
> without error.
>
> I'm concerned with whether you can be sure that the 999th time you
> run it the database won't randomly decide to declare a serialization
> failure for reasons you couldn't predict were possible.
Now you're questioning whether SERIALIZABLE transaction isolation
level is useful. Probably not for everyone, but definitely for some.
As stated before, the trade-off is that you don't need to know what
all the transactions look like or which ones might be run concurrently
in order to guarantee that you avoid anomalies; but you need to be
able to handle the rollback of any serializable transaction. Nothing
in the proposed techniques would create problems like you describe in
transactions running at other isolation levels, or preclude taking out
explicit locks to prevent this where you need additional guarantees --
like needing to be sure that a transaction won't be rolled back with a
serialization failure after 10 hours.
-Kevin