Question

We have a table called Contracts. These contract records are created by users on an external site and must be approved or rejected by staff on an internal site. When a contract is rejected, it’s simply deleted from the db. When it’s accepted, however, a new record is generated called Contract Acceptance which is written to its own table and is derived from data that exists on the contract.

The problem is that two internal staff members may each end up opening the same contract. The first user accepts and a contract acceptance record is generated. Then, with the same contract record still open on the page, the second user accepts the contract again, creating a duplicate acceptance record.

The quick and dirty way to get past this is to retrieve the contract from the db just before it’s accepted, check the status, and produce an error message saying that it’s already been accepted. This would probably work for most circumstances, but the users could still click the Accept button at the exact same time and sneak by this validation code.

I’ve also considered a thread lock deep in the data layer that prevents two threads from entering the same region of code at the same time, but the app exists on two load-balanced servers, so the users could be on separate servers which would render this approach useless.

The only method I can think of would have to exist at the database. Conceptually, I would like to somehow lock the stored procedure or table so that it can’t be updated twice at the same time, but perhaps I don’t understand Oracle enough here. How do updates work? Are update requests somehow queued up so that they do not occur at the exact same time? If this is so, I could check the status of the record in th SQL and return a value in an out parameter stating it has already been accepted. But if update requests aren’t queued then two people could still get into the update sql at the exact same time.

Looking for good suggestions on how to go about this.

Answer 1

In general, there are two approaches to the problem

Option 1: Pessimistic Locking

In this scenario, you’re pessimistic so you lock the row in the table when you select it. When a user queries the Contracts table, they’d do something like

SELECT *
  FROM contracts
 WHERE contract_id = <<some contract ID>>
   FOR UPDATE NOWAIT;

Whoever selects the record first will lock it. Whoever selects the record second will get an ORA-00054 error that the application will then catch and let them know that another user has already locked the record. When the first user completes their work, they issue their INSERT into the Contract_Acceptance table and commit their transaction. This releases the lock on the row in the Contracts table.

Option 2: Optimistic Locking

In this scenario, you’re being optimistic that the two users won’t conflict so you don’t lock the record initially. Instead, you select the data you need along with a Last_Updated_Timestamp column that you add to the table if it doesn’t already exist. Something like

SELECT <<list of columns>>, Last_Updated_Timestamp
  FROM Contracts
 WHERE contract_id = <<some contract ID>>

When a user accepts the contract, before doing the INSERT into Contract_Acceptance, they issue an UPDATE on Contracts

UPDATE Contracts
   SET last_updated_timestamp = systimestamp
 WHERE contract_id = <<some contract ID>>
   AND last_update_timestamp = <<timestamp from the initial SELECT>>;

The first person to do this update will succeed (the statement will update 1 row). The second person to do this will update 0 rows. The application detects the fact that the update didn’t modify any rows and tells the second user that someone else has already processed the row.

In Either Case

In either case, you probably want to add a UNIQUE constraint to the Contract_Acceptance table. This will ensure that there is only one row in the Contract_Acceptance table for any given Contract_ID.

ALTER TABLE Contract_Acceptance
  ADD CONSTRAINT unique_contract_id UNIQUE (Contract_ID)

This is a second line of defense that should never be needed but protects you in case the application doesn’t implement its logic correctly.