Date: Tue, 10 Dec 1996 22:06:05 GMT
Server: NCSA/1.4.2
Content-type: text/html
Last-modified: Wed, 04 Dec 1996 07:31:46 GMT
Content-length: 3920
Transaction Support in the SPIN Operating System
Transaction Support in the SPIN Operating System
Last modified:Sun Nov 24 20:01:50 1996
Why am I doing this?
Supporting transaction service at the operating system level has been
considered a bad idea, because operating systems haven't been
traditionally flexible
enough to accommodate various needs of database systems.
- Application can not take advantage of
specialized locking or logging. For example, there are many researches
on concurrent Btree updates. Since such techniques depend on precise
data placements, it is difficult to implement them inside OS.
- and more...
Therefore, almost all of the commercial database systems are built
on top of generic operating systems. This approach is not without problems;
they were pointed out 15 years ago by Mike
Stonebraker and have never seen satisfactory solution till now.
- Double buffering; database engine usually maintains the buffer
on ordinary user memory, so the data is duplicated on user buffer
and kernel file buffer. Also, user buffer leads to memory
underutilization.
- and more...
I'm trying to solve this dilemma by using
SPIN. SPIN allows an untrusted user code to be downloaded into
the kernel space. I'm trying to write a high performance distributed
transaction service which is both fast and flexible
(and
doesn't crash, hopefully...).
As a first step, I will write a simple transactional memory like
provided in Camelot.
Yasushi Saito
is working on the project with Brian Bershad. I'm also getting a lot
of help from
people in SPIN and
Opal.
Papers and other resources
Here's a random collection of papers and source codes that I culled
from the world.
yasushi@cs.washington.edu