I have a database with some tables and also data in them.I need to implement for all tables optimistic concurrency.
I was wondering what would be the best way.
Query with a predicate will be created on the application side.
My concern is how-to store the rowversion(timestamp) value.
First I was thinking of using ora_rowscn for rowversion value,but then I realised I have to recreate all tables to set up ora_rowscn. Maybe just adding a some kind of timestamp column would be good,but then I would be forced to create and save a new timestamp value for every update in the application.
Any ideas ?
Optimistic concurrency control transactions involve these phases: Begin: Record a timestamp marking the transaction's beginning. Modify: Read database values, and tentatively write changes. Validate: Check whether other transactions have modified data that this transaction has used (read or written).
The optimistic method of concurrency control is based on the assumption that conflicts of database operations are rare and that it is better to let transactions run to completion and only check for conflicts before they commit.
The following tables follow an example of optimistic concurrency. At 1:01 p.m., User2 reads the same row. At 1:03 p.m., User2 changes FirstName from "Bob" to "Robert" and updates the database. The update succeeds because the values in the database at the time of update match the original values that User2 has.
Optimistic concurrency derives its name from the optimistic assumption that collisions between transactions will rarely occur; a collision is said to have occurred when another transaction updates or deletes a row of data between the time it is read by the current transaction and the time it is updated or deleted.
Oracle has a built-in package for optimistic locking called OWA_OPT_LOCK. This can be used to generate a checksum for any row like this:
select owa_opt_lock.checksum('SCOTT','EMP',ROWID)
from emp
where empno = 123;
This can be called when originally getting the record and again before saving the changes; if the 2 values are different, someone else has changed the record since you got it.
A very simple but effective pattern is to first fetch the whole row about to be edited without keeping a lock. When you are finally ready for the update, augment the where clause with clauses like COLUMNA='OLDVALUEA'
. The number of changed records indicates if some other modification interfered with your optimistic update or not.
This method will notice all modifications that are still in effect when you try update. Any method relying on checksums can falsely indicate that no modifications have taken place. The reliability you need depends on your application. I would not bet human lifes on checksums. However, I would try not to rely on optimistic updates in this case either.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With