Subject Transaction mode question
Author Kjell Rilbe

If SinĂ¡tica Monitor reports a transaction as "Read Committed no Record
Versions, Read Write", am I right in these assumptions:

1. Read/write mode, i.e. both selects, updates, inserts and deletes are

2. On each statement, for each record, it will access only the latest
record version, in effect ignoring MVCC.

3. Assuming the lack of wait/no wait info means "no wait": If the latest
record version is uncommitted, it will report a lock conflict, even if
the attempted operation is a read/select.

This is in an OR framework (ECO, a bit like NHibernate). I think it uses
this mode for all operations. It would seem to me that this mode limits
the number of concurrent operations more than is really motivated.

I am considering to use "rec versions" instead., in which case I would
expect the above to turn into:

2. On each statement, for each record, it will *read* the latest
committed version. Does this count per statement start time or is it
"asynchronous" so that a record version committed by another transaction
in the middle of a statement execution will be read by that statement?

3. Assuming the lack of wait/no wait info means "no wait": On each
statement, for each record, a *write* will fail with a lock conflict
error if there is an uncommitted record version.

In view of the OR framework, this transaction mode would mean that when
reading it will always get the latest possible data. If the reads are
"async" as I ask in point 2, the data received runs the risk of being
inconsistent, which is not good. When writing data, if the OR framework
doesn't add any explicit checks for record versions, it will overwrite
changes written by other transactions, without noticing, assuming the
other changes are committed. Uncommitted changes will result in an
exception, due to lock conflicts.


Kjell Rilbe
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64