has_many collection(force_reload=TRUE) hits cache under lock!

In a has_many association, collection(true) failed to execute a fresh SQL command, despite force_reload being set to true, and instead hit the cache, inside a transaction / lock!. The problem only occurred with concurrent requests and multiple mongrels, in the 2nd concurrence/lock!. Here's the simplified/offending code...

where as... Order has_many :order_items And :order_items has_many :quantities

Class Order

def update

Order.transaction do
  self.lock!
  order_item = self.order_items.first
  order_item.quantities(true).clear
  order_item.quantities << OrderItemQuantity(...stuff here...)
end

end end

The problem was that in the 2nd concurrence, "order_item.quantities(true).clear" was failing to delete the quantities created by the 1st concurrence. The solution was to replace:

order_item.quantities(true).clear

...with...

OrderItemQuantities.delete_all(["order_item_id = ?", order_item.id])

So here are some facts, in the 2nd instance/concurrence/lock!:

1. "order_item.quantities(true).clear" was hitting the cache (according to the log), despite the (true) which (as far as I understand) should have forced a reload.

2. The quantities cache was stale (returning quantities from before the 1st instance/concurrence/lock!. This caused the clear to do nothing (because the id's returned from quantities(true) no longer existed because of the 1st concurrence).

3. OrderItemQuantities.all(["order_item_id = ?", order_item.id]), when inserted before the "order_item.quantities(true).clear", issued fresh SQL and returned the correct list of quantities (where "correct" means the quantities created by the 1st concurrence/lock!).

Using Rails 2.1.1, MySQL, storage engine is InnoDB for all tables.

Unless I misunderstand the documentation, order_item.quantities(true) should have issued fresh SQL rather than hitting the cache.