Tanel, There's a whole boatload of race conditions in that sort of replication architecture. As murali has pointed out, single-side commits create manual rollback situations - plus what happens when both transactions succeed, but in the delay between the two commits one side begins operating on a just-changed record....
And then the last problem situation is invalidating one side of the database when a link goes down - how do you bring it back into sync? Do you journal transactions? Thanks, Matt -- Matthew Zito GridApp Systems Email: [EMAIL PROTECTED] Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Tanel Poder > Sent: Monday, December 15, 2003 6:29 AM > To: Multiple recipients of list ORACLE-L > Subject: Re: Re: 24 x 7 x 365 > > > Jonathan, > Thanks for this valuable information. > However, I'm using regular commits, not "distributed" > two-phased ones and I just have simple code to handle the > situation where servers return different success/error codes. > > Tanel. > > > > > > There is a problem with this approach > > that may only become apparent at high > > concurrency. > > > > Since you are operating with two-phase > > commits, you may come up against the case > > where "writers block readers". > > > > Your client issues a commit to both servers. > > Each server get the PREPARE message, > > and when both have responded, each gets > > the COMMIT message. > > > > Between the PREPARE and COMMIT, > > any blocks updated in the transaction > > cease to be available to ANY query > > that started after the PREPARE arrived. > > > > For the (hopefully) brief interval between > > the prepare and commit, neither database > > knows whether the transaction as a whole > > has prepared or committed, so any process > > that wants to see the current version of the > > data has to wait until there is a known current > > version. > > > > In a high-concurrency system, a problem > > that used to be "buffer busy waits" on updates > > only can turn into enqueue waits on updates > > and queries. > > > > Regards > > > > Jonathan Lewis > > http://www.jlcomp.demon.co.uk > > > > The educated person is not the person > > who can answer the questions, but the > > person who can question the answers -- T. Schick Jr > > > > > > One-day tutorials: http://www.jlcomp.demon.co.uk/tutorial.html > > > > > > Three-day seminar: > > see http://www.jlcomp.demon.co.uk/seminar.html > > ____UK___November > > > > > > The Co-operative Oracle Users' FAQ > > http://www.jlcomp.demon.co.uk/faq/ind_faq.html > > > > > > ----- Original Message ----- > > To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > > Sent: Saturday, December 13, 2003 8:19 PM > > > > > > Yep, I also think so. I'm currently developing a small > prototype for this > > kind of transparent proxy, which I'll post here when it's stable... > > > > Tanel. > > > > > Tanel, > > > > > > I think this is a good solution, provided the application > can handle > > > two phased commit protocol across both the databases, else there > > > could be orphan records on one or both these databases. > > > > > > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.net > > -- > > Author: Jonathan Lewis > > INET: [EMAIL PROTECTED] > > > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > > San Diego, California -- Mailing list and web > hosting services > > > --------------------------------------------------------------------- > > To REMOVE yourself from this mailing list, send an E-Mail message > > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > > the message BODY, include a line containing: UNSUB ORACLE-L > > (or the name of mailing list you want to be removed from). You may > > also send the HELP command for other information (like subscribing). > > > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Tanel Poder > INET: [EMAIL PROTECTED] > > Fat City Network Services -- 858-538-5051 http://www.fatcity.com > San Diego, California -- Mailing list and web hosting services > --------------------------------------------------------------------- > To REMOVE yourself from this mailing list, send an E-Mail message > to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in > the message BODY, include a line containing: UNSUB ORACLE-L > (or the name of mailing list you want to be removed from). You may > also send the HELP command for other information (like subscribing). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Matthew Zito INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
