this disclosure of the invention is submitted in furtherance of the constitutional purposes of the u . s . patent laws &# 34 ; to promote the progress of science and useful arts &# 34 ; u . s . constitution , article 1 , section 8 . this invention is described in the context of controllers for data storage systems , such as disk array controllers . it may be used , however , in other environments as well as other types of controllers . a disk array data storage system includes a disk array of multiple storage disks and a disk array controller 14 coupled to coordinate data transfer to and from the storage disks . the disk array controller is coupled to the disk array via one or more interface buses , such as a small computer system interface ( scsi ). the disk array controller includes a memory map store in the form of nvram that provides for persistent storage of information , as well as common dynamic random access memory ( dram ). one use for the nvram is to store any mapping information used to locate data on the storage disks . this mapping information is updated as data is written to , removed from , or relocated on the storage disks . fig1 illustrates a transaction object 10 used in a disk array controller to manage data contained in dram and nvram . one example use of transaction object 10 is to manage a complex series of action items concerning allocation and deallocation of available memory space on the disk array . the transaction object 10 itself is embodied as firmware in the disk array controller . transaction object 10 includes a roll forward log 12 and a roll back log 14 . the roll forward log 12 is a fifo ( first - in - first - out ) table that lists action items to be performed in the future by the controller in order to accomplish a certain task . action items 1 and 2 are illustrated in the roll forward log . for instance , the disk array controller may wish to allocate a block of memory for storing user data . this allocation task involves a series of action items to effectuate formation of available memory space on the disk array . the roll back log 14 is a lifo ( last - in - first - out ) table that lists the inverse of action items that have already been performed by the controller . inverse action item 1 is illustrated in the roll back log . for example , during the memory block allocation task , the roll back log 14 tracks the action items in the order that they are performed and sequentially lists appropriate inverse action items that would undo them . according to one aspect this invention , an action item which specifies clearing the roll forward log of all its action items is placed in the roll back log . this is illustrated in fig1 by the action item &# 34 ; clear roll fwd log &# 34 ; before inverse action item 1 in the roll back log 14 . this clear operation effectively deletes all action items in the roll forward log 12 , such as action items 1 and 2 . there are essentially five services performed by transaction object 10 of this invention : ( 1 ) add an action item to the roll forward log 12 ; ( 2 ) add an inverse action item to the roll back log 14 ; ( 3 ) a commit transaction ; ( 4 ) an abort transaction ; and ( 5 ) recover from power failure . these services are used by other firmware modules or objects to make their own action item series atomic . when using the transaction , a firmware module user reaches a point where it decides either to &# 34 ; commit &# 34 ; the transaction or &# 34 ; abort &# 34 ; it . upon informing the transaction object of the need to commit , the controller will complete the transaction by performing the action items in the roll forward log 12 . conversely , upon requesting abort , the controller will undo the transaction by working in reverse order back through the inverse action items listed in the roll back log 14 . according to an aspect of this invention , the commit event which delineates between committing transactions and aborting them is defined as a single instruction to clear the roll back log 14 . fig2 illustrates the interaction of the five services . at the start 20 of a transaction , the action item of clearing the roll forward log 12 is initially placed in the roll back log 14 ( step 22 ). as process continues , various action items are logged in either the roll forward log 12 or the roll back log 14 as appropriate ( steps 24 and 26 ). during this time , the controller is performing action items to manage the data stored in the disk array . at some point , the user of a transaction finishes logging action items in the transaction . at that point , the user decides whether the transaction will be committed or aborted ( step 28 ). if the user decides to commit ( i . e ., the &# 34 ; yes &# 34 ; branch from step 28 ), then the controller executes the commit process ( step 30 ), which is described below with respect to fig3 . on the other hand , if the user decides to abort ( i . e ., the &# 34 ; no &# 34 ; branch from step 28 ), the controller executes the abort sequence ( step 32 ), which is described below with respect to fig4 . in either case , the process is restarted ( step 20 ). if power fails during any phase of this process , flow is immediately directed to the recover service at step 34 . this is graphically indicated by the dotted bracket leading to step block 34 . following the recover service , operation is returned to start 20 . the single action item of clearing the roll forward log is guaranteed by the controller to be atomic with respect to power failure . an atomic action will either be completely performed or not performed . it cannot be left partially performed during power failure . the roll forward log is therefore either cleared or not cleared at power failure ; there is no partial clearing . this invention effectively renders atomic an entire complex series of action items performed in nvram with respect to power failure . the series of action items will either be completed or alternately undone depending upon whether the single atomic action item of clearing the roll back log has been performed . this method thereby takes a single instruction and leverages it against all actions for roll forward and roll back logs in order to produce an atomic operation with respect to power failure . fig3 shows a preferred sequence of steps for the commit function 30 of fig2 . at step 40 , the roll back log 14 is cleared . since the commit point has been reached , the transaction shall not be undone so there is no reason to remember the inverse action items listed in the roll back log . the roll forward log 12 is then executed to perform any action items listed in it to thereby complete the transaction ( step 42 ). afterward , the roll forward log 12 is cleared at step 44 in preparation for the next use of the transaction object . flow then returns to the start of a new series of action items and once again , the action item to clear the roll forward log is placed in the roll back log at step 22 ( see fig2 ). fig4 shows a preferred sequence of steps for the abort function 32 of fig2 . upon a decision to abort the process , the roll back log is executed to essentially undo the action items previously performed by the controller ( step 50 ). since the action item to clear the roll forward log is listed in the roll back log , the roll forward log is automatically cleared during execution of the roll back log . afterward , the roll back log is also cleared ( step 52 ). the transaction object is then prepared for the next use , as indicated by the initializing step of listing the &# 34 ; clear roll forward log &# 34 ; instruction in the roll back log ( step 22 ). fig5 illustrates a preferred sequence of steps for the recover function 34 of fig2 which are to be performed in the event of recovering from a power failure . the first two steps 60 and 62 are performed in the illustrated sequential order . they are to first execute the roll back log 14 and then subsequently execute the roll forward log 12 . this sequence of steps completes the action items if the commit event was reached prior to power failure , or undoes the action items if the commit event had not been performed prior to power failure . recall that the commit event is the single instruction to clear the roll back log . if it has been performed by the controller prior to power failure , the roll back log is clear and there are no action items to perform in step 60 . in this case , the controller desires to finish the action items and thus , the roll forward log is executed at step 62 . conversely , if the commit event has not been reached by the controller prior to power failure , the roll back log will still contain action items . the controller desires to undo the action items and thus , the roll back log is executed at step 60 . this includes the action item of clearing the roll forward log since it is listed in the roll back log . as a result , the roll forward log is clear by the time it is executed at step 62 . after execution , both logs are cleared at steps 64 and 66 . this ensures that both are clear prior to reinitializing the transaction object . the transaction object can then be initialized , which once again includes the task of listing the action item to clear the roll forward log in the roll back log ( step 22 ). variations of the process are possible . for instance , an action item to clear the roll back log can be placed in the roll forward log . this would essentially combine steps 40 and 42 of the commit sequence in fig3 in that the roll back log would automatically be cleared during execution of the roll forward log . as another example , steps 64 and 66 in the recover sequence of fig5 can be reversed without effecting operation . the above description relates to use of a single transaction object for purposes of explanation . it is noted , however , that there can be multiple transaction objects in various states of completion at the same time . each commit , abort , and recovery decision can be made independently for each transaction . the methods of this invention offer significant advantages . one advantage is that the operational sequence is simplistic and global , handling essentially any event , including power failure , that might occur . another advantage is that the controller operation is rendered atomic with respect to power failure . still another advantage is that a single instruction is used to coordinate essentially all actions in the roll forward and roll back logs . yet another advantage is that the recovery process works correctly even if the power fails repeatedly during the recovery process . in compliance with the statute , the invention has been described in language more or less specific as to structural and methodical features . it is to be understood , however , that the invention is not limited to the specific features shown and described , since the means herein disclosed comprise preferred forms of putting the invention into effect . the invention is , therefore , claimed in any of its forms or modifications within the proper scope of the appended claims appropriately interpreted in accordance with the doctrine of equivalents .