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 { $dbh.do(...) };
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?
Sam.
