Cursors control—through several options—concurrent access, which occurs when more than one user accesses and updates the same data at the same time. During concurrent access, data can become unreliable without some kind of control. To activate the particular concurrency control desired, specify one of the following options when you open a cursor:
Option |
Result |
|---|---|
CUR_READONLY |
Updates are not permitted. |
CUR_LOCKCC |
The set of rows currently in the client buffer is locked when they are fetched inside a user-initiated transaction. No other user can update or read these rows. Updates issued by the cursor owner are guaranteed to succeed. No locks are held unless the application first issues begin transaction. Locks are held until the application issues a commit transaction. Locks are not automatically released when the next fetch is executed. |
CUR_OPTCC and CUR_OPTCCVAL- |
Rows currently in the buffer are not locked, and other users can update or read them freely. |
To detect collisions between updates issued by the cursor owner and those issued by other users, cursors save and compare timestamps or column values. Therefore, if you specify either of the optimistic concurrency control options (CUR_OPTCC or CUR_OPTCCVAL) your updates can fail because of collisions with other updates. You may want to design the application to refresh the buffer and then retry updates that fail.
The two optimistic concurrency control options differ in the way they detect collisions:
Option |
Method of Detection |
|---|---|
CUR_OPTCC |
Optimistic concurrency control based on timestamp values. Compares timestamps if available; otherwise, saves and compares the value of all non-text, non-image columns in the table with their previous values. |
CUR_OPTCCVAL |
Optimistic concurrency control based on values. Compares selected values whether or not a timestamp is available. |
