| Transactions are  obviously going  to be expensive  and complicated,
| which
| is why I suggested implementing them outside the core:

[...]

| That's  not  quite  sufficient  for  full  transactions  either.  We
| should also allow
| user code to  replace the assignment op in the  virtual machine too.
| (And
| whatever else  Transactions.pm decides should be  abortable.) Hmm. A
| transaction
| could  be a  simple  copy-on-write with  an  exception handler  that
| just restored
| all  original values.  That'd  be efficient  too  because SVs  can't
| move.

In  the RFC,  you  can find  a  suggestion  to a  new  pragma for  the
transction-behaviour.  Now  the  RFC  is  in the  phase  that  it  can
control various  data sources,  which can acts  as a  two-phase commit
clients!  Not  only   database  servers,  but  a  simple   file  on  a
filesystem also!  (read v5  of the RFC.  It is still  on the  way). Do
you know how effective it can be?

| Somebody ;) should  go through the more challenging RFCs  and try to
| distill
| out  general  features  we  could  put in  the  internals  to  allow
| implementing
| the  RFCs outside  the core.  That way  we wouldn't  hold up  Perl 6
| while waiting
| for a research project to finish.

I don't  know how it  can be implemented outside  the core. I  think a
new   keyword   and   a   new    pragma   is   required.   Maybe   the
transaction-handler can be  a shared object, but I think  this must be
in the core.

This  can make  perl more  acceptable for  the business:  perl objects
are now  can be  transaction-safe! That can  be rolled  back, supports
two-phase commits, etc.

What it needs in the core is pretty small btw:

- a new keyword, which is similar to "local"
- some extension to the TIE interface (some new callbacks)
- some extension to the object interface (new callbacks)
- two-phase  commit handler,  rollback coordinator  (the above  two is
  connected to this: very simple algorhythm!)
- lock/mutex handler
- (optional,  because   it  is   a  very  tough   alg:)  multi-version
  concurrency control (MVCC) like in postgreSQL

If   we  forget   about   the  MVCC,   then   all   things  are   very
straightforward, aren't  they? It is  _not_ complicated at all.  It is
all Perlish!

\---

dLux
--
         < Szabó, Balázs Tibor - dLux > - HuLUG - Allinphos
      ( mailto:[EMAIL PROTECTED] http://www.dlux.hu ICQ: 30329785)

Reply via email to