Skip to content

Use optimistic locking

Kamil Trzciński requested to merge use-optimistic-locking into master

What does this MR do?

Removes the usage of pessimistic locking in favor of optimistic which is way cheaper and doesn't block database operation.

Since this is very simple change it should be safe. If we receive StaleObjectError message we will reload object a retry operations in lock.

However, I still believe that we need this one: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7005 as this will reduce a load on Database and FS. This changes a behavior from:

Pesimistic locking (previous behavior)

For updating

  1. SELECT * FOR UPDATE (other updates wait on this)
  2. we update ci_pipeline
  3. latest_build_status
  4. enqueue: (use: transition :created -> :pending)
  5. [state_machine] we are in state created, we can go to pending
  6. [state_machine] ci_pipeline.status = created
  7. [state_machine] ci_pipeline.save
  8. [state_machine] after_transition: (if for success): PipelineSuccessWorker on Sidekiq
  9. release DB lock

If no update is required

  1. SELECT * FOR UPDATE (other updates wait on this)
  2. we update ci_pipeline
  3. latest_build_status
  4. we are in pending, we can't transition to pending, because it's forbidden
  5. release DB lock

Optimistic locking (implemented by this MR)

For updating

  1. latest_build_status
  2. enqueue: (use transition :created -> :pending)
  3. [state_machine] we are in state created, we can go to pending
  4. [state_machine] ci_pipeline.status = created
  5. [state_machine] ci_pipeline.save
  6. [state_machine] [save] where(lock_version: ci_pipeline.lock_version).update_all(status: :created, updated_at: Time.now)
  7. [state_machine] [save] unless we_updated_row then raise ObjectInconsistentError

If no update is required

  1. we update ci_pipeline
  2. latest_build_status
  3. we are in pending, we can't transition to pending, because it's forbidden

Why was this MR needed?

We have been seeing a number of problems when we migrated Pipeline/Build processing to Sidekiq. Especially we started seeing a lot of blocking queries.

We used a pessimistic locking which doesn't seem to be required. This effectively allows us to fix our issues with blocked queries by using more efficient method of operation.

What are the relevant issue numbers?

Issues: https://gitlab.com/gitlab-com/infrastructure/issues/623 and https://gitlab.com/gitlab-com/infrastructure/issues/584, but also there's a bunch of Merge Requests that try to improve behavior of scheduled jobs.

cc @pcarranza @yorickpeterse @stanhu

Merge request reports