RE: Re: 24 x 7 x 365

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: mzito_at_gridapp.com
Cell: 646-220-3551
Phone: 212-358-8211 x 359
http://www.gridapp.com



> -----Original Message-----

> From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com] 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" <ORACLE-L_at_fatcity.com>

> > 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: jonathan_at_jlcomp.demon.co.uk

> >

> > 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: ListGuru_at_fatcity.com (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: tanel.poder.003_at_mail.ee

> 

> 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: ListGuru_at_fatcity.com (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: mzito_at_gridapp.com

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: ListGuru_at_fatcity.com (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).