develooper Front page | perl.perl6.language | Postings from July 2005

Re: Database Transactions and STM [was: Re: STM semantics, the Transactionalrole]

Thread Previous | Thread Next
Sam Vilain
July 23, 2005 23:50
Re: Database Transactions and STM [was: Re: STM semantics, the Transactionalrole]
Message ID:
Yuval Kogman wrote:
>>>everyone gets to choose, and another thing I have in mind is the
>>>Transactional role...
>>>	DBI::Handle does Transactional;
>>>To the STM rollbacker and type checker thingy this means that any IO
>>>performed by DBI::Handle invoked code is OK - it can be reversed
>>>using the Transactional interface it proposes.
>>Is this needed, when you can just;
>>   atomic {
>>      unsafeIO { $dbh.begin_work };
>>      unsafeIO { $ };
>>      unsafeIO { $dbh.commit };
>>   } CATCH {
>>      $dbh.rollback;
>>   };
> Why have STM like constructs if that's what you're going to do
> anyway?
> The point is to be able to compose unrelated atomic block into one
> atomic action.
> If we don't get some separation of concerns from STM we might as
> well be using locks.

Sorry for the necro-equine flagellation, but I think STM would have to
support general nesting to be useful.  In fact I'd be highly surprised
if the Haskell STM implementation doesn't already support it.

We'll need this, because a "transparent" object persistence layer won't
want data to mismatch the database in the event of a rollback, as
Tangram takes some effort to ensure now in Perl 5.  So it will be doing
its own atomic { } stuff that will all "commit" to memory on the
successful database commit, or undo changes in the event of a rollback.

The end goal is to be able to give the DB layers enough hooks that we
can say a well written one Just Works™ in the face of atomic { }.

Does that seem relevant to the point you were making?


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About