On 10/16/2010 9:58 AM, Jonathan Bond-Caron wrote:

> For example, some databases don't bother with write conflicts:
>
> PostgreSQL in SERIALIZABLE isolation level will not block/wait if
> conflicting UPDATE statements happen.
>
> It provides a "read snapshot in isolation" but allows 'conflicting writes'
> to happen concurrently.
> This is somewhat ok since all reads by concurrent transaction are isolated.

Hmmm... I think that PostgreSQL will send a fatal error to the
second concurrent update if that transaction is in their "serializable"
mode if the first updater commits, just as Firebird does. They have a
"read committed" mode that is closer to "write committed" where the
second updater waits and applies its update to the newly committed
version. That's what InnoDB, MySQL's transactional storage engine,
does. It gives the odd effect that SELECT and SELECT ... FOR UPDATE
can give different results.

>

>> A second, more general question is whether anyone knows of a database
>> in commercial use that tries to order transactions based on their
>> relative start time (as Reed does) rather than having each new
>> transaction note the state of other transactions at that instant?
>
> Good question, I think the commercial databases don't share enough their
> internals :)

That's what I like about open source.


Cheers,

Ann