G
gus bjorklund
Guest
> > So based on that, it sounds like a SQL Server error message is the "good" one to look for because it almost certainly means that updates on both the SQL and OE side of things will be properly rolled back. > > On the other hand, an error message from the OE database (ie. unique constraint violation for example) may be a much more scary one ... because there is a possibility that the error message could arise *after* the SQL Server update operation has already committed. (IE. the OE database update operation is to be rolled back, but the SQL Server update will not.) > > This is nice information to know. Have you ever seen this type of thing in documentation? Personally, I would rather that this would have just failed by default (ie. with an optional parameter, -feelingextremelylucky, to allow the two databases to participate in the same "transaction"). > Errors that happen /before/ commit processing begins will cause all participants to be rolled back. Constraint violations should occur before commit processing. The two-phase commit protocols is what enabled multiple databases (and other things) to participate in the “same” global transaction. But each participant also has its own local transaction. Coordinating the several local transactions so that all achieve the same outcome is the purpose of two-phase commit protocols. Not sure what you mean by "allow the two databases to participate in the same “transaction” “.
Continue reading...
Continue reading...