How to block records when are read?

Question

In my case, I have groups of records and when I update one of them, I need to update the rest of the records of the group. So to ensure that I update all of them and I need to ensure that no other records are added to the group when I am updating one record of the group. Also I need to ensure that a record of the group is not removed in the middle of the process because then I update a record that really isn't belong to the group.

So I am thinking in the possibility to block a record just when it is read. In the documenation I see the the more restrictive isolation is the serializable isolation, but I have a doubt because it says:

Statements cannot read data that has been modified but not yet committed by other transactions.

Other statement can't read the record if it modified and not committed, but can be read if still is not modified, so I can get unupdated information that I need to decide what related records I need to update.

So I would like to know if it is another way to block records just when it is read. I know that with the hints I can block a table when I execute a statement, but block all the table. The process that I need to execute it's very fast, but I would like to avoid the need to block all the table and block only the records that I need.

Answer 1

Yes, you can use SERIALIZABLE isolation level. In the next point in the document you linked, it says:

No other transactions can modify data that has been read by the current transaction until the current transaction completes.

Other transactions cannot insert new rows with key values that would fall in the range of keys read by any statements in the current transaction until the current transaction completes.

Which is what you need.

Remember that you can change the isolation level. You can raise it to SERIALIZABLE to do your job and then move it back to what you had before. The locks put in place when the isolation level was SERIALIZABLE will stay in place until the end of transaction.

Answer 2

Manipulating multi-view concurrency control (MVCC) is something to be done with care. Yes, SERIALIZABLE is a two-edged sword that can get you into trouble. But, here's the key point in the documentation you referenced:

Other transactions cannot insert new rows with key values that would fall in the range of keys read by any statements in the current transaction until the current transaction completes.

It sounds like protecting key ranges is really what you want to do, and serialized is the only somewhat sane way to do that (that I know of).

So, you are on the right track with SERIALIZABLE. Just be careful, test thoroughly, and make your transactions complete quickly.