At 04:04 AM 9/8/2011, Andrew Sullivan wrote:
>On Wed, Sep 07, 2011 at 02:51:32PM -0500, Merlin Moncure wrote:
> >
> > @andrew s: going SERIALIZABLE doesn't help if you trying to eliminate
> > cases that would push you into retrying the transaction.
>
>Well, no, of course. But why not catch the failure and retry? I
>guess I just don't get the problem, since I hear people say this all
>the time. (I mean, I've also seen places where 'upsert' would be
>cool, but it doesn't seem trivial to do in a general way and you can
>do this with catch-serialization-error-and-retry, I think?)
Doesn't catching the failure and retrying mean writing more code?
Need extra code:
1) to handle the savepoint.
2) to correctly distinguish between "retryable" errors and
"nonretryable" errors.
3) to retry transactions.
More code to debug, test, document and support :).
In contrast, the "lock table, insert if row does not exist, update if
it exists" and rollback everything if "stuff happens" seems simpler
to do correctly.
I personally prefer to leave as much code writing to others (e.g.
those writing Postgresql, programming languages and libraries),
because I assume they are much better at writing code than I am. Plus
I usually don't have to document and support their code ;).
Regards,
Link.
