/--- On Wed, Sep 06, 2000 at 11:23:37AM -0400, Dan Sugalski wrote:
| >Here's some high-level emulation of what it should do.
| >
| > eval {
| > my($_a, $_b, $c) = ($a, $b, $c);
| > ...
| > ($a, $b, $c) = ($_a, $_b, $_c);
| > }
|
| Nope. That doesn't get you consistency. What you need is to make a
| local
| alias of $a and friends and use that. You also need to lock down
| those
| variables so other threads will block if they write to them, and
| make
| copies if they need to only read them.
|
| It also means that if we're including *any* sort of external
| pieces (even
| files) in the transaction scheme we need to have some mechanism to
| roll
| back changes. If a transaction fails after truncating a 12G file
| and
read the rfc please. I don't want to explain it 3rd time.
| writing out 3G of data, what do we do? And what does another
| thread that's
| *only* reading that file during the transaction see? Does it
| block? Does it
| see the pre-changed version? (Which is the normal course of action
| in
| database systems)
|
| This proposal's looking to roll in pretty much everything that
| makes a
| modern relational database system really useful. (Whether SQL is
| useful is
| an argument we won't get into at the moment... :) The ideas look
| simple on
| the surface, but they have a huge number of ramifications, and
| implementing
| them properly's not easy.
|
| If we want to, that's great, but we do need to think it out really
| carefully before we do.
|
\---
Please read the RFC and AFTER you can make suggestions. These _all_
are mentioned in the rfc!
I know I am not perfect english, so some part of the rfc might be
misunderstandable, but please help me to develop the fully working
method.
I have started to plan what we need in the core to support very cool
things (transaction-enabled vars). I designed the TIE and object
interface. That's ALL we need, and we have a great working solution.
I have demonstrated that with an example!
Most objections, arguments are unnecessary arguments, most things
are covered in the RFC. Not everything is clear, but I cannot get
_any_ good sugestion about things that are not covered by the rfc.
I hear objections about "too complex", "impossible", and so on. I
don't want to take over the world, I only want to make a _simple_
extendable (by modules) transaction-control system, which uses parts
of the perl, which are already written (because perl is rewritten to
support threads). Only one small thing is new: 2pc, but this is a
very small alg!
I don't want more. I don't want to save state of
non-transaction-enabled objects. I want to develop my own objects,
which are transaction safe, and I want to do transactions with that.
And IF we implement that feature in perl6, most people thinks that
perl is ready for the enterprise solutions.
Only ONE language is supports transactions now (which is not a
special database-language), and this is Bolero by Software AG
(AFAIK). This is a quite expensive, and (in design) quite good, and
developed to control business events. It is based on java virtual
machine. In the business they have business objects,
transaction-objects, permanent objects, etc. Transaction-enabled
object is one of the main features of that language.
In contrast, perl is a general purpose swiss army knife, and can be
used for nearly all purposes, except for controlling transactions in
"perlish" way. Ok, we can write transaction controllers out of core,
but it makes our perl code unnecessary large, because we only need
_very small_ addition to the core to win a very cool feature!
So I want to get suggestions from those, who thinks my idea can be
worked out with minimal effort.
The open questions are:
- how complicated the versioning of the variables, do we need this?
- is somebody out there who thinks he can write the code that
implement this?
- is there any modification which makes it more powerful and make it
more simple?
dLux
--
Isten ovja a kepernyot! God save the screen!
