Rails - Nov 2004 - Transactions

I''m really enjoying learning about ActiveRecord, which seems to be an
elegantly useful approach to the object-relational problem. Right now,
I''m trying to understand the canonical way to use transaction support:

The following comments are based on the documentation currently found
at api.rubyonrails.org:

1) The first example:

  transaction do
    david.withdrawal(100)
    mary.deposit(100)
  end

Was this meant to be "transaction", or was
"ActiveRecord::Base.transaction" meant here? if just
"transaction",
what file would I "require" for that?

2) A more complete version of this example would, presumably, be something like:
  dave = Client.find(...)
  mary = Client.find(...)
  transaction do
    david.withdrawal(100)
    mary.deposit(100)
  end

It''s my impression that, written this way, the code would have a race
condition (unless ActiveRecord is re-reading david & mary from the
database after a database transaction is started), and should really
be written this way:

  transaction do
    dave = Client.find(...)
    mary = Client.find(...)
    david.withdrawal(100)
    mary.deposit(100)
  end

3) Similarly, with this example, also from the documentation:

Account.transaction(david, mary) do
    david.withdrawal(100)
    mary.deposit(100)
end

I have the same concern--will Account.transaction ensure the integrity
of the records david & mary at the beginning of the transaction?
Should I wrap the whole thing (including the find''s, in another
"transaction do" statement?

4) In the discussion on exception handling, it''s not clear to me what
exceptions might be raised by ActiveRecord or the backend database.
It''d be really helpful to show an example which handled (and retried?)
database rollbacks caused by deadlocks, for example.

5) I *think* that the documentation is declaring the difference
between a general transaction and an object level transaction is that
the object level transaction tells ActiveRecord about the objects
involved in the transaction so that it can roll them back locally,
whereas the generic one won''t do this.

I would be grateful for any clarification of any of the above, and
examples would be most helpful.

Thanks,
Bob Sidebotham

On Mon, 29 Nov 2004 12:46:31 -0800, Bob Sidebotham
<bob.sidebotham-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> It''s my impression that, written this way, the code would have a
race
> condition (unless ActiveRecord is re-reading david & mary from the
> database after a database transaction is started), and should really
> be written this way:
> 
>   transaction do
>     dave = Client.find(...)
>     mary = Client.find(...)
>     david.withdrawal(100)
>     mary.deposit(100)
>   end
P.S. I just realized that I''m making the assumption that dave &
mary''s
account balances are stored directly in dave and mary. If this isn''t
true, if they are actually stored in related records which are fetched
within the transaction, then there would be no race hazard. This does
bring up another issue, however: within the transaction, I want a
guarantee that the data hasn''t been updated externally prior to the
transaction. Since records can be cached, and might, in the future, be
cached more aggressively, what are the guarantees, exactly? I''m
worried that either dave or mary might have been updated by another
process just after being cached, so that the withdrawl/deposit
functions might be operating on stale data.

I''m curious what people do about this in "real life". It
seems to me
that the simplest thing to do, for a web application, is to wrap the
whole action path in a single transaction. I''m curious to know what
other people actually do.

Thanks,
Bob


Bob