Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle wrote: > Rick Silton wrote: > > 6. Atomic commit support (but I don't believe this implies > > serialization with checkout & update which I believe is > > the real issue. This is also not on by default and I get > > the impression it isn't universally endorsed.) > Atomic commits is just one of those things that people kept asking for, so > when someone came up with a working idea I implemented it... I've never > used it beyond the testing stage though because it's annoying (if you're > commiting a large number of changes over a link and the link drops out it's > a pain have to resync the client with the server state rather than just > continue the commit where it left off). > The primary goal of atomicity - avoiding corruption - has always been in > cvs, since the RCS files are handled atomically anyway (I don't see half a > commit as a corruption since nothing is lost... when the server comes back > up the developer just repeats the commit and carries on as if nothing had > happened). I agree that the benefits to the person doing the commit are marginal at best, but what does it mean to 'avoid corruption'? I think that it's more than just making sure that all the changes make it or none of them. I'm concerned about what happens *while* a commit is taking place. If someone starts a checkout while another commit is in progress then it is very possible for the sandbox to be "corrupted" in the sense that it is inconsistent with itself. I.e. the module compiles fine before the commit, it compiles fine after the commit, but a sandbox created during the commit fails. By the way, I've seen this happen quite regularly. If I remember my database theory (which is suspect) then what is needed is for readers (of the elements being written) to be held off until the commit is finished - i.e. the transactions need to be serialized. So... does the atomic commit also imply serialization? If not, has anyone considered work to do this? - Rick