[9fans] Adding transaction semantics to Plan9

[9fans] Adding transaction semantics to Plan9

[G.David]

Hello everyone.  I have been quiet for a while, but that is just
the quiet before the storm.  I have some new things I want to
discuss!

My current project is to add transaction support to the process
model with full log protected file servers.  I plan to use the
multi-version consistency model and distributed commits to multiple
file servers involved in the transaction.

The primitives are from a Bell Labs paper "A Flexible Transaction
Facility for an Object-Oriented Database" from 5 Dec 92.  (To keep
it in the family.)  The system is will not be object-oriented
(unless you want to consider a "file" or a "directory" a class).
The primitives are useful for implementing transaction models that
are interesting.

The changes are extensive.  The file protocal 9P is changed (to add
the idea of a transaction to the current idea of a user.)  Several
system calls are changed and a few added to internalize the idea of
a transaction.  I am just starting.

I am planing three transaction modes.  Read Committed, Serializable
and Plan9.  The latter is Read Committed and Write Commit.
The primitives allow "cursor stability", savepoint/rollback,
nested and chained transactions, to name a few.

The plan for the system is to build low cost data intensive
application servers for the Internet.  I belive that transactional
semantics are required in any large scale distributed system and
current systems are cost prohibitive.  In addition, the current
state of the art is to run a database on top of an operating system.
I believe there is a lot of efficiences to be gained by making
them one.

Just pick an issue and let's get going...

David Butler
gdb@dbSystems.com

[9fans] Adding transaction semantics to Plan9

[G.David]

From: Rich Salz <rsalz@opengroup.org>
>have you looked at the IETF TIP protocol?
>Like all IETF work (well except for patented public-key stuff :), IETF
>specs can be freely implemented without charge.  TIP is a transaction
>protocol intended to sit over a variety of transports.  It's being
>proposed by Tandem and Microsoft.

I wonder when using the word *irco*oft will automatically discount
anything as a *real* solution, the way *BM does now (but they are
getting better.) [Sorry, the devil made me do it.]

>Check out http://www.ietf.org/html.charters/tip-charter.html

Thanks for the URL.  I read the draft and it is the old 70's
2P Commit Protocol.  Many databases only implement up to
isolation level 2 and sometimes 3.  In those cases old 2PC
works fine.  To go to isolation level 4 in a distributed database
you need *more*.

I will implement TIP on the TCP side of the platform (in the CPU
servers) but I need something stronger on the IL side with the
file servers.

Thanks for the info.

David Butler
gdb@dbSystems.com

[9fans] Adding transaction semantics to Plan9

[G.David]

[This didn't come in via the mailing list,
I had to pluck it off news]

From: forsyth@caldo.DEmon.co.UK <forsyth@caldo.DEmon.co.UK>
>i'd have put transaction control files in the name space
>of the transaction server.  those files
>would be written to announce and describe transactions,
>and set transaction modes, and perhaps read to discover state.
>i'd do this for much the reason
>that plan 9 has got /net/tcp and /net/ether
>rather than specialised system calls for sockets.

I thought about this first (it is Plan9!).  Adding to each
server an /adm/trans file that could be written with "start",
"abort", "commit", etc.  There are many problems with this.
First, the process may not know all of the servers that are
bound in.  Next, 9P does not preserve process boundaries only
user.  (Look at the 9P calls from a fork some day.)  Even if you
addressed those issues, how does the server know one read/write
from another?  The mnt driver multiplexes things very well.

>it would be useful, however, to see what your new
>system calls are, to get a more concrete feel for why
>you felt you needed them.

The calls are like begintrans(type), committrans(), aborttrans();
pretty conventional.  The kernel would then have to add the transaction
to most messages and allow for some "file systems" to ignore them.
This is where you add 9P messages and the associated entry points
to each 9P server. (Read that as each device driver needs to
be changed to support or ignore transactions.)

The bottom line is that each 9P message (with some added like
attacht, clonet, precommitt, committ, clunkt) would go from
Tblah [tag] [fid] ... to Tblah [tag] [tid] [fid]

David Butler
gdb@dbSystems.com