I have a revision system setup with two tables, one contains the current revision of an entity and the other contains each revisions for the entities. I need to perform some locking on my model so that creation of the new revision and the updating of the header record happen atomically. This works great now in development mode with just the one user and a single ruby process, but as soon the site goes live and I open up more processes, the locking will be totally pointless.
Ideally I’d like to still use the header record, rather than a ‘current’ column on the revisions table. Perhaps I could store the locks on another daemon, do any Rails specific applications that do this already exist?
What solutions have people used in situations like this?
I have a revision system setup with two tables, one contains the current
revision of an entity and the other contains each revisions for the
entities. I need to perform some locking on my model so that creation of the
new revision and the updating of the header record happen atomically. This
works great now in development mode with just the one user and a single ruby
process, but as soon the site goes live and I open up more processes, the
locking will be totally pointless.
Ideally I'd like to still use the header record, rather than a 'current'
column on the revisions table. Perhaps I could store the locks on another
daemon, do any Rails specific applications that do this already exist?
What solutions have people used in situations like this?
I think your best bet is using the db for synchronization. Picking the
right isolation level for your transaction may be enough. If not,
there's always locking.
Guess I’ll have to wait for Rails 1.2