Do the DISK objects contain a reference to a DISK-PAIR? What about the reverse?
Can DISK's be in more than one DISK-PAIR? I will assume some answers to these so I can give a design. Suppose that DISK's just contain other information, but do not refer to DISK-PAIR's and and can only exist in a single pair. If so, then the state really should be in the DISK-PAIR and the update should proceed this way: create DISK-PAIR referring to the two disks and with state = ONLINE No update to the DISK is necessary. If, on the contrary, the DISK's should have a reference to the DISK-PAIR to ensure that they are never in more than one DISK-PAIR, the update would proceed this way: create DISK-PAIR referring to the two disks with state = OFFLINE read the first disk state. If it has been assigned to a PAIR, abort, otherwise set it to refer to the new DISK-PAIR. If the update fails, delete the DISK-PAIR and abort. read the second disk. if it has been assigned to a PAIR, unassign the first disk and abort otherwise set it to refer to the new DISK-PAIR. If the update fails, unwind the update to the first disk, delete the DISK-PAIR and abort update the DISK-PAIR to have state = ONLINE If desired, you can update each disk at this point to have state = ONLINE. This is really just to speed up checking if a disk is on-line. The logic would be: if a disk is not a member of a pair, it is off-line else if a disk has state = ONLINE, it is on-line else if the pair for the disk has state = ONLINE, the disk is on-line (this check will only happen very rarely for very newly paired disks) This update sequence is guaranteed to succeed or fail completely. Moreover, a disk can only be in a single pair and the online status of a disk can be determined by checking the disk to see if it is in a pair and if that pair has state ONLINE. Can you move the ONLINE state to the DISK-PAIR? On Mon, Mar 29, 2010 at 7:24 PM, zd.wbh <zd....@163.com> wrote: > Thanks for your quick reply, Ted. > > we are implementing a distributed system, using zookeeper for master > metedata persistence. There's DISK object and DISK-PAIR object. when > creating a DISK-PAIR, we need to first create a znode indicating DISK-PAIR > object and updating the corresponding two DISK's state from DISK_OFFLINE to > DISK_ONLINE, these operations need to be done as a whole. > > 2010-03-30 > > > > Will > > > > 发件人: Ted Dunning <ted.dunn...@gmail.com> > 发送时间: 2010-03-30 10:11 > 主 题: Re: How to ensure trasaction create-and-update > 收件人: email@example.com > > > > This is not a good thing. ZK gains lots of its power and reliability by > not > trying to do atomic updates to multiple znodes at once. > > Can you say more about the update that you want to do? It is common for > updates like to be such that you can order the updates and do without a > truly atomic transaction. For instance if one file is a list of other > files > (say for a queue) and you need to create a file and add a reference in the > list of files, you can generally be safe creating the new file first and > then doing an atomic update on the list of files secondly. If your process > fails between the two operations, then you may generate a small number of > garbage files (this number can be substantially decreased by careful use of > try/finally) which might require a cleanup process to run occasionally to > find unreferenced and old files. > > On Mon, Mar 29, 2010 at 6:54 PM, zd.wbh <zd....@163.com> wrote: > > > we'd like to store some metadata in zookeeper in our upcoming project, > > here is a special but common case: we need to create a new znode, in the > > mean while, update another znode data. These manipulation(a create and a > > update) need to be done as atom. We don't want to see a successful > creation > > and a failure updating. Is there a convenient way to ensure this > operation? > > Can you give me some tips? > > > > I've looked into the src code, there is a tedious way to do. Extend > > zookeeper instruction, struct a "createAndUpdate" interface and a txn > > request, let DataTree to ensure the integrity. Will this do and the only > > way? > > >