On 5/5/05, John Lam <jlam / iunknown.com> wrote:
> Yes - what you're saying does make sense.
> 
> I was thinking about cases where you're performing transactions
> against large objects, say a hash table.

Well, I do these against large objects. Transaction::Simple is a
fundamental support library for PDF::Writer. Just about the only
time it sees update is when I need to update it for PDF::Writer ;).

> Since the target objects don't know anything about transactions
> (and you don't know anything about their internal state) then this
> would wind up duplicating a lot of state.

Well, that's not really true. With Transaction::Simple, the target
object does become transaction-aware -- but it has nothing to do
with a "transaction manager" or database transactions.

> However, if an object were Tx aware, then it would know how to
> manage its state in face of a transaction manager. Adding a single
> entry to a hash table wouldn't require copying the entire table
> first - you'd simply record the fact that you are adding a record
> and add it at commit-time.

Right. This isn't a transaction log that can be replayed. This does
the simplest possible thing (which is why there are a number of
limitatiosn): it takes a Marshal.dump of the object. 

> At this point you'll need to have 2-phase commit protocols -
> telling each object to prepare to commit before actually
> committing. Any object that fails to prepare to commit aborts the
> entire Tx.

Well, I don't know if it's currently used, but DHH added
Transaction::Simple support to ActiveRecord a while back so that
when you do a transaction with ActiveRecord, if the database
transaction fails, it also causes the object transaction to fail.

> This is probably a lot more complicated than what you have
> envisioned (after all these are *Simple* transactions). I think
> this will still be very useful for many situations where you
> aren't modifying very large objects (or are not doing many such Tx
> in parallel).

Perhaps. Something like this might be possible with a Builder
object, but it would require a level of wrapping that I'm not -- at
this point -- interested in dealing with.

-austin
-- 
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca