Re: Database Transactions and STM [was: Re: STM semantics, the Transactional role]
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.
Re: Database Transactions and STM [was: Re: STM semantics, the Transactional role]
On Sun, Jul 24, 2005 at 18:50:28 +1200, Sam Vilain wrote:
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.
Uh, yeah, that's exactly my point.
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.
So what API hooks that can compose like STM gives you do you
propose, for making things roll back when STM gives up and goes to
try the block of code again?
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?
Yes =)
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /methinks long and hard, and runs away: neeyah!!!
pgpoM4eSBp0jj.pgp
Description: PGP signature
Re: Database Transactions and STM [was: Re: STM semantics, the Transactional role]
On Mon, Jul 18, 2005 at 15:16:16 +1200, Sam Vilain wrote:
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.
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me wields bonsai kittens: neeyah
pgpR96sEUAYbm.pgp
Description: PGP signature
Re: Database Transactions and STM [was: Re: STM semantics, the Transactional role]
On 7/18/05, Sam Vilain [EMAIL PROTECTED] wrote:
Is this needed, when you can just;
atomic {
unsafeIO { $dbh.begin_work };
unsafeIO { $dbh.do(...) };
unsafeIO { $dbh.commit };
} CATCH {
$dbh.rollback;
};
Shouldn't that `CATCH` block be within the `atomic` block? Or did I
miss something?
Aankhen
Database Transactions and STM [was: Re: STM semantics, the Transactional role]
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;
};
Of course, these unsafeIO calls can go inside a higher level wrapper
for the DBI, assuming that it is possible to detect whether or not
we are running in an atomic{ }, and which atomic block we are in.
As for the efficiency of things, hate to say it but that's really up
to the backend in use, and it's highly unlikely that anything other
than Parrot or GHC will support atomic{ }.
However a standard Role for this kind of behaviour might make sense.
Maybe draw up a prototype?
Sam.
