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
