Tanel,
If this is the approach, then quite a bit of code would have to be developed on the front end to handle transaction integrity. For example when one fails and the other has completed the write successfully, they will have to be physically removed. What about if the record that is commited was already read by another session.
Basically avoiding any orphan records or avoiding data reconciliation between the two.
I also agree with Jonathan, while two phased approach is used for such kind of activities, there could be tremendous overhead depending on how intensive the transaction rates are.
Murali
Tanel Poder <tanel.poder.003@mail.ee> wrote:
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"
> 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@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@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@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@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).
