Robert Klemme wrote:
> On 12.09.2011 19:22, Andy Colson wrote:
>> There are transaction isolation levels, but they are like playing
>> with fire. (in my opinion).
> You make them sound like witchcraft. But they are clearly defined
> - even standardized.
Yeah, for decades. Developing concurrency control from scratch at
the application level over and over again is more like playing with
fire, in my book.
> Granted, different RDBMS might implement them in different ways -
> here's PG's view of TX isolation:
> http://www.postgresql.org/docs/8.4/interactive/transaction-iso.html
Oh, that link is *so* day-before-yesterday! Try this one:
http://www.postgresql.org/docs/9.1/interactive/transaction-iso.html
> In my opinion anybody working with RDBMS should make himself
> familiar with this concept - at least know about it - because it
> is one of the fundamental features of RDBMS and certainly needs
> consideration in applications with highly concurrent DB activity.
+1
Understanding what levels of transaction isolation are available,
and what the implications of each are, is fundamental. Just as
there are cases where a foreign key constraint doesn't exactly work
for what you need to enforce, there are cases where serializable
transactions don't fit. But where they do fit, developing the
equivalent from scratch all over again is not as safe or productive
as using the built-in feature.
-Kevin