DynamoDB Dynomite Optimistic Locking
Important: These docs are for the outdated Jets 5 versions and below. For the latest Jets docs: docs.rubyonjets.com
Dynomite makes it easy to use optimistic locking when you save data. Just add enable_locking or enable_locking to your model.
class Post < ApplicationItem
enable_locking
end
Optimistic locking works with the lock_version field by default. Dynomite uses it to check if someone else has changed the record since it was opened. If that happens, it throws the error Dynomite::Error::StaleObject.
post1 = Post.first
post2 = Post.first
post1.title = "post 1 edit 1"
post1.save
post2.title = "post 1 edit 2"
post2.save # Raises a Dynomite::Error::StaleObject
It’s up to you to handle the conflict, usually by rescuing the exception and implementing business logic to sort it out.
Locking Field
You can change the locking version field by specifying it as an argument.
class Post < ApplicationItem
enable_locking :optimistic_lock_version
end
Then
post = Post.create(title: "test")
post.optimistic_lock_version # 1
The methods enable_locking, enable_optimistic_locking, locking_field are aliases. So this also works:
class Post < ApplicationItem
locking_field :optimistic_lock_version
end
Locking Field Migration
The lock field should be an integer. So if you’re adding an index via a migration, make sure you’re adding it as a number.
class CreateProducts < Dynomite::Migration
def up
create_table :posts do |t|
t.add_gsi "lock_version:number"
end
end
end