On Tue, Mar 6, 2012 at 1:47 AM, Kjell Rilbe <kjell.rilbe@...> wrote:

>
> 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
> allowed.
>

Yes.

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

MVCC has three effects in Firebird: consistent state of the database for
readers,
"undo" information stored in the database, detection of conflicting
writes. In
read-committed no record veersion mode, you avoid the first benefit but
still
get the others.

> 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.
>

I think the default is WAIT, but am often wrong. But yes, if the setting is
no record versions, you get an immediate error if you try to read a record
that another transaction is updating.

>
> 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.
>

More than is rational. But many application developers don't trust MVCC -
or at least don't trust it in Firebird, so they try to imitate the worst
behavior
they know.

>
> 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?
>

Asynchronous, I think, but here I'm even less certain. That should be
relatively easy to test.

>
> 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.
>

Yes.

>
> 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.

Inconsistent a statement and inconsistent between statements.

> 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.
>

No. Although a read committed transaction reads changes that have been
committed after the transaction start, it can not update or delete records
that
were inserted or updated after it started. So you can read a new value, but
you can't change it.


Good luck,


Ann


[Non-text portions of this message have been removed]