Rails 5中限制has_many关联子记录数的正确方案探讨

Great question—this is such a common pitfall when enforcing association limits, especially once your app starts seeing any real concurrency. Let’s break this down step by step:

Why app-level validations aren’t enough #

First, let’s confirm why those naive app-level checks (like validating parent.children.count < limit before creating) fail. Imagine two requests hit your server at almost the exact same time, both checking if a parent has fewer than 5 children. Both see the count is 4, pass the validation, and both create a child. Suddenly you’ve got 6 children attached to that parent—oops, race condition wins.

These checks work fine in low-traffic environments, but once you have concurrent writes, they’re basically useless for enforcing hard limits.

Is a table-level EXCLUSIVE lock the right fix? #

Short answer: No, that’s overkill and will tank your performance. A table-level EXCLUSIVE lock blocks all writes (and even some reads, depending on your database) to the entire parent table. That means every request trying to modify any parent or its children has to wait in a single queue—terrible for scalability.

The right lock here is a row-level EXCLUSIVE lock on the specific parent record you’re modifying. This only blocks other requests trying to work with that exact parent, leaving all other records in the table free to be accessed normally.

How to implement this correctly #

In most ORMs (like Rails, since you mentioned has_many), you can use built-in methods to handle row-level locking and transactions together. For example, in Rails:

parent = Parent.find(params[:parent_id])
parent.with_lock do
  # Inside this block, the parent record is locked with an EXCLUSIVE lock
  # and we're running in a transaction
  if parent.children.count < 5
    parent.children.create!(child_params)
    # Handle success
  else
    # Handle the "limit exceeded" error
    raise ActiveRecord::RecordInvalid, "Parent can't have more than 5 children"
  end
end

What’s happening here:

• with_lock automatically starts a transaction and acquires an EXCLUSIVE lock on the parent row.
• Any other request trying to modify this parent (or its children, if you’re enforcing the limit this way) will wait until the lock is released.
• The count check and child creation happen atomically, so there’s no window for a race condition to slip in.

Key things you might be missing #

• Don’t forget database-level safeguards
  Even with row-level locks, it’s smart to add a database-level safety net. For example, in PostgreSQL, you could create a trigger that checks the child count before inserting a new record. This prevents cases where someone might bypass your app logic (like running raw SQL) and exceed the limit.

• Batch operations need the same lock
  If you’re ever creating multiple children for a parent in a batch, make sure the entire batch operation runs inside the locked block. Otherwise, you could still end up with too many children if the batch size pushes you over the limit.

• Lock timeout handling
  Databases will wait for locks by default, but if a request holds a lock too long, other requests might time out. You should handle timeout exceptions in your app (like ActiveRecord::LockWaitTimeout in Rails) and return a meaningful error to users, instead of letting the request hang.

• Avoid over-locking
  Only lock the parent record you need—never the entire table. Row-level locks are lightweight and won’t impact other parts of your app, which is critical for maintaining performance as your user base grows.

内容的提问来源于stack exchange，提问作者Edward