In message <20140404231316.GA19617@runtux.com> <20140404231316.GA19617@runtux.c
om>,
Ralf Schlatterbeck writes:
>This is normal serialisation behaviour: The database if free to not
>perform updates that are subsequently overwritten by a later
>transaction.
>
>So both my transactions seem to have started with the same old tx_Source
>value with the nonce 84ef0e4322500b890fb0 and both put this old value
>into their journal entry (thats the old tx_Source when both of my two
>concurrent transactions were started).
> [...]
>So there is nothing wrong with roundups serialisation.
>
>Currently roundup is using the lowest isolation level supported by
>PostgreSQL, "Read committed".
>See also:
>http://www.postgresql.org/docs/9.1/static/transaction-iso.html
>
>Setting a higher isolation level, at least "repeatable read" would work
>for this case, at least if the auditor would read the tx_Source property
>before updating it (but this is done by the detector framework anyway,
>so no need to modify the detectors). In that case one of the
>transactions would be aborted with a serialization error.
>
>Currently the isolation level isn't settable in roundup, maybe we should
>make this configurable?
>
>Only Postgres seems to support the concept of isolation levels although
>defined in the SQL standards...

Well from 

  http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html

mysql with innodb has:

  SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
    {
	 REPEATABLE READ
       | READ COMMITTED
       | READ UNCOMMITTED
       | SERIALIZABLE
     }

  This statement sets the transaction isolation level, used for
  operations on InnoDB tables.

  Scope of the Isolation Level

  You can set the isolation level globally, for the current session, or
  for the next transaction:

      With the GLOBAL keyword, the statement sets the default
      transaction level globally for all subsequent sessions. Existing
      sessions are unaffected.

      With the SESSION keyword, the statement sets the default
      transaction level for all subsequent transactions performed within
      the current session.

      Without any SESSION or GLOBAL keyword, the statement sets the
      isolation level for the next (not started) transaction performed
      within the current session.

Also https://www.sqlite.org/sharedcache.html seems to indicate that
sqlite with shared cache can support read_uncommitted mode.