Wim,
just to clarify, take look and use snap are not mutually exclusive.
For the moment forgot the disable snap feature and the special batch update transaction.
You take locks on a table/record when you are in a read-write transaction. But the level of your lock depend on you reserving clause (and on the strategy choose by Rdb).
For a table you can specify 2 words, the first one is how you accept others access the table concurrently with you, the second how you access the table:
shared/protected/exclusive read/write
exclusive mean that you want to be alone on the table, in this case and only in this case you don't write to snap.
protected mean you accept reader
shared you accept reader/writer
Rdb escalate an shared lock on a table into a protected if the strategy choose is sequential.
You also specified the isolation level needed:
read committed/repeatable read/serializable
Rdb don't support dirty read mode.
There are, also, others options but outside the scope of this thread.
On Rdb cost of snapshot is "paid" by writer for an eventual reader.
Each time you update a record (table record, index record, system record,...) Rdb use a snap page (if necessary more than one) linked to the live page to write the old version of the record. The documentation contains a full description of the structure of a data/snap page, you can also use the rmu/dump command to view the content of a data/snap page, very useful.
Briefly, a read only transaction read the data page check the record version using the TSN (transaction sequence number), if this version is not the correct one, start to follow the chain of snap page/record.
If you have disabled snap, you have something very similar to "shared read isolation level read committed".
JFP
