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!!!
pgpdx2kqoKejI.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
pgpWWcj1zYyYB.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.
STM semantics, the Transactional role
Hey! Welcome back our show, gay camels[1] in denial! On todays show,
those who can't shut up won't, and will send you another email!
Today's issues cover STM, and just that.
Perl6 should have some kind of
atomic {
...
}
going on, AFAIK.
We already know how to keep it happy: make the changes local, help
consistency checks be optimizable, blah blah blah. Haskell does it
with the fact that most of the code is pure, and that means you only
have to check for a few things. Haskell also has type purity, that
keeps IO out of the mess.
So, here is a bit of food for thought, on efficiency and usability
of STM in Perl6.
Usability of STM in perl can be enhanced on two aspects - TIMTOWDI,
so we can allow IO, or not allow it, without special magic -
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.
Let's get carried away: The Exclusive role - an object which can
only atomically talk to one thread at a time, or the Pure role - a
read only object that can be omitted from journaling (remember the
pure function trait?).
Now to deal with efficiency...
First of all, to make it fast we have something almost as good as
functional purity - lexical scopes. And they are being pushed like
mad, too. As long as something was created within the current atomic
scope, and didn't leak out of the scope (detectable at compile time
for simple values), it's safe, and can be omitted from the journal.
What's troubling me is deeper data types. What are the semantics
Perl 6 will have WRT data cloning and threads? I think by now we
have a tight enough language that share by default can actually work
- we have lexical control over many things, no more globals for
lexical settings, and so forth. OTOH, we also have COW in parrot,
which suggests that duplicating everything is cheap (personally I'd
like to have both, and precise control over what the thread you are
creating will be).
If everything is copy by default, we only have to journal shared
data. We can optimize for this on the thread level - a copied thread
has cheaper STM later.
One more aspect we can propose is that if a function is known to be
unsafe, we can pessimize the STM operation - kind of like
sub foo : locked {
}
in perl 5 (i forget how it's actually written, but I remember I saw
it). Does anybody have any idea how we can guess this?
Anyway, I'm done with my brainstorming... Sorry for the post being
so chaotic.
Ciao!
[1] http://lambda.org/
--
() Yuval Kogman [EMAIL PROTECTED] 0xEBD27418 perl hacker
/\ kung foo master: /me spreads pj3Ar using 0wnage: neeyah!!!
pgphgrAQBlnw9.pgp
Description: PGP signature
