[RADIATOR] failover SqlDB destinations

[Michael]

I patched my version of radiator to failover to the next sql source when an sql time out error occurs. What I did was:

In 'sub initialize' i added an offset value:
$self->{DBOffset}    = 0;

In 'sub reconnect' i add this value to $i of the 'for' for cycling through the DBSources:
for ($i = 0 + $self->{DBOffset}; $i < @{$self->{DBSource}}; $i++)

In 'sub prepareAndExecute' right before the 'while' statement which loops the number of times the current sql statement will be attempted, I reset this offset value to 0.
$self->{DBOffset}=0;

Also in 'sub prepareAndExecute' I changed the timeout detection 'if' statement to increment the DBOffset value
if( $@ && $@ =~ /timeout/ ) {
              $reason = "SQL Timeout";
              $self->{DBOffset}++;
}



So the result is, when an sql statement timeout occurs, the DBSource start point when re-connecting ($i) is incremented so that the next DBSource is used, and hopefully no timeout.  It seems to be working better so far, but an obvious undesirable situation arises when the 2nd DBSource is in use, and a timeout occurs, DBOffset will be 1, and the $i start point to re-connect, will be the same sql server that timed out, and it will have to time out again in order to move to the next sql server.

It's not perfect, but this is better for me at this point.






On 11-08-02 10:00 AM, Michael wrote:
>
>
> Has anyone found any solutions/patches for the sql timeout failover issue with radiator?  When radiator executes an sql statement on an sql server that times out not on connecting, but the statement itself, radiator disconnects and reconnects to the same sql server to try again.  It never seems to failover to the next sql destination.  So, having multiple sql sources seems to be irrelevant with the issue of statement time outs.
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>
>