From: Luke Kanies <luke@...>
Date: 2006-08-20T05:49:22+09:00
Subject: Re: Refactoring transactional support within Puppet (long)

On Aug 18, 2006, at 2:11 PM, ara.t.howard@noaa.gov wrote:
>
> 1) make transactions re-entrant AND singleton
>
> 2) make __all__ operations take place in a transaction
>
> eg
>
>   def initialize
>     ...
>     @transaction_mutex = Mutex.new
>     @in_transaction = false
>     ...
>   end
>
>   def transaction
>     @transaction_mutex.sychronize do
>       if @in_transaction
>         yield
>       else
>         it = @in_transaction
>         begin
>           @in_transaction = true
>           yield
>         ensure
>           @in_transaction = it
>         end
>       end
>     end
>   end
>
>   alias_method "t", "transaction"
>
>
> ...
>
>   def foo() t{ @foo = 42 } end
>   def bar() t{ @bar = 42 } end
>   def foobar() t{ foo and bar } end

Hmm.  If I do this, then at the very least I want to organize things  
so that the developer doesn't need to know about transactions; either  
I use intermediate methods that handle the fact that it's in a  
transaction, or I do some method-renaming so that the direct methods  
get replaced with methods that go through a transaction.

That's somewhat immaterial, though, I guess. You're basic point is  
that there should only ever be one transaction at a time, right?   
There'd be no concept of sub-transactions, but anything that got done  
in the middle of a transaction would automatically be included in the  
transaction.

I'm not sure about always working within a transaction; I'm not sure  
it's reasonable to assume that every user of Puppet's library will  
want to use transactions, but I'm not sure it harms anything to do  
so.  I'd probably want things set up so that if there is a  
transaction, all work is done within that transaction, and if there  
is not one, then no transaction is used.

So that gives me an idea of how to handle transactions essentially  
transparently (with some modification necessary to make it  
transparent to the developer, also), but I still need to figure out  
how to transparently handle the three-phase collect, compare, commit  
operations.  It seems that some controlling process would need to do  
that, and currently my transaction is the controlling process, but  
with your recommendation the transaction moves completely into the  
background (which is probably where it belongs, largely).

There's also a lot of logging, error handling, and event handling  
that currently take place in the transaction, so I would need to  
translate that into these behind-the-scenes transactions, but I  
wouldn't guess that would be too difficult.

Thanks.

-- 
Luke Kanies
http://madstop.com | http://reductivelabs.com | 615-594-8199