This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 130
=head1 ABSTRACT
Transactions are quite important in a database-enabled application.
Professional database systems have transaction-handling inside, but
there are only a few laguage out there, what supports transactions
in variable level.
=head1 DESCRIPTION
In short, we have "local" keyword, which changes a value of a
variable for only the runtime of the current scope. The
transaction-enabled variables should start up like "local", but IF
the currenct scope reaches at the end, it then copied into the
global one.
We need to get a new keyword for defining such a variable, I think
"transaction" is too long, we could use "safe" for this reason. Look
at how it works:
Preferred syntax:
sub trans { my ($self,@params)=@_;
safe $self->{value}=$new_value;
# ...
die "Error occured" if $some_error;
function_call(...)
# ...
} ;
Meaning (in semi perl5 syntax):
sub {
local $self->{value}=$new_value;
# ...
die "Error occured" if $ome_erre;
function_call(...)
# ...
global $self->{value}=$self->{value};
};
=head1 IMPLEMENTATION
At the first glance, it is trivial after implementing "local". Only
one check should be added when destroying the local variables.
But the truth are far from that if we look farther.
What about tied variables? Multithreading?
The only acceptable solution I see is the following:
at the point $self->{value} is made "safe", the system put a lock on
the variable, and if any other thread wants to access it, then it
simply waitsuntil the variable is released. We have problems can
come up with this: deadlock situations.
We could use use more intelligent locking (read-write locks,
timestamped values), and this is now a very complex database
problem. We should take some code from PostgreSQL :-)
In the case of the "tie": (first, unintelligent locking method)
Suppose $self is a tied hash.
safe $self->{value}=$new_value is interpreted as:
$save=(tied %$self)->FETCH("value");
tied(%$self)->STORE("value",$new_value);
lock $self->{value};
at the end of a successful scope:
unlock $self->{value};
at the case of an error:
tied(%$self)->STORE("value",$save);
unlock $self->{value};
In the first implementation (in perl6) we should use this simple
locking scheme. This is quite powerful in non-multithreaded
environment also!o!
=head1 REFERENCES
RFC 1: Implementation of Threads in Perl
RFC 19: Rename the C<local> operator
RFC 63: Exception handling syntax
RFC 64: New pragma 'scope' to change Perl's default scoping
RFC 80: Exception objects and classes for builtins
RFC 88: Structured Exception Handling Mechanism (Try)
RFC 106: Yet another lexical variable proposal: lexical variables
made default without requiring strict 'vars'
RFC 119: object neutral error handling via exceptions
