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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
