: 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
>
>
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 commit
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 ap
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
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 th
