Optimistic Locking 6: which ORA_ROWSCN?

Continuing my series on using ORA_ROWSCN to achieve optimistic locking, let’s zoom in on ORA_ROWSCN itself. I've been asking myself this question:
  • ORA_ROWSCN can be maintained at the block level or the row level. What is the difference and which one should we use?

Optimistic Locking 5: “Read-consistent” SCN

Continuing my series on using ORA_ROWSCN to achieve optimistic locking, let's zoom in on the query API and the "read-consistent" SCN of the data it returns. I've been asking myself these questions:
  • How do we get read-consistent data in the query API if it does more than one SELECT?
  • How do we know the exact value of the "read-consistent" SCN?

Optimistic Locking 4: the Good

After discussing lost updates, the SCN and my theoretical use case, here is my idea for doing SCN-based optimistic locking. I'm going to simplify and emphasize the advantages here; limitations and gruesome details will come later.

Optimistic ORA_ROWSCN 3: the Use Case

My goal is to show how ORA_ROWSCN can help deal with the problem of "lost updates". Before that, I need to explain the use case I have in mind: an OLTP application that provides a transactional API, using JSON for data interchange, across a stateless connection.

Optimistic ORA_ROWSCN 2: the SCN

In my previous post, I covered lost updates. Before saying how ORA_ROWSCN can help avoid them, I need to talk about the SCN. It's hard to be simple and correct about such a fundamental element of the Oracle database, but I'll try.

Optimistic ORA_ROWSCN 1: Lost Updates

I've gotten lots of feedback about my proposal to use ORA_ROWSCN for optimistic locking. I'm going to start over in more detail and try to leave less scope for misinterpretation. Thanks to all for your comments, especially Jonathan Lewis who saved me from some technical doubts. "Optimistic locking" is a type of solution to the problem of "lost updates". So what do we mean by "lost update", anyway?

Optimistic Locking with one Timestamp?

A reader called chris asked me a good question about optimistic locking: why not use a “user-defined” scn (e.g. timestamp) as an extra column to achieve the same goal as ORA_ROWSCN? Well, chris, you'd have to use one per row, not one per transaction.

More on Optimistic Locking with ORA_ROWSCN

Thanks to comments by Tony Hasler and pingbacks from Jeff Kemp, here's more detail on how optimistic locking works with SCNs, especially with respect to "restarts" during update.

Optimistic Locking: One SCN to rule them all

Previously I showed how to avoid lost updates with ORA_ROWSCN. Now let’s create an API that avoids lost updates with just one SCN. What kind of API? A transaction consists of one or more changes to data that should happen together: either all should happen or none. When the transaction commits, all the changes happen; […]