From owner-freebsd-fs  Wed Oct  1 21:06:25 1997
Return-Path: <owner-freebsd-fs>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA29891
          for fs-outgoing; Wed, 1 Oct 1997 21:06:25 -0700 (PDT)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA29885
          for <freebsd-fs@FreeBSD.ORG>; Wed, 1 Oct 1997 21:06:21 -0700 (PDT)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id EAA07386; Thu, 2 Oct 1997 04:05:06 GMT
Date: Thu, 2 Oct 1997 13:05:06 +0900 (JST)
From: Michael Hancock <michaelh@cet.co.jp>
To: Terry Lambert <tlambert@primenet.com>
cc: Chris Csanady <ccsanady@bob.scl.ameslab.gov>, brandon@roguetrader.com,
        wilko@yedi.iaf.nl, freebsd-fs@FreeBSD.ORG
Subject: Re: Known problems with async ufs?
In-Reply-To: <199709242308.QAA23263@usr03.primenet.com>
Message-ID: <Pine.SV4.3.95.971002124817.7227A-100000@parkplace.cet.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-fs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, 24 Sep 1997, Terry Lambert wrote:

> It will also mean that there are no hooks to guarantee transactions
> are idempotent (multiple atomic transactions considered as an
> all-or-nothing unit) for something like a user accessible transaction
> tracking system.

I think you're looking for another term.  Idempotent transactions are like
reads where you can repeat the transaction without ill-effects.
Non-idempotent transactions modify the state of the system such that they
can't be repeated, say rmdir foo.

Multiple atomic transactions that are atomic can be restated as an atomic
transaction.

Regards,


Mike