RE: sql-relay
> It's harder if you want every query to be able to automatically retry on > another database if it fails. For that, you would need to add some > extra code to catch the exception, recognize it as a connection failure, > make a new connection, and retry the query. I don't see anything on the > SQL-Relay pages about this sort of ability. We crafted a module that does this for our Oracle databases. To save anybody else the effort, here are the errors we identified as connection errors that deserve a reconnection attempt: Oracle errors: ORA-00028 your session has been killed ORA-00603 ORACLE server session terminated by fatal error ORA-01034 ORACLE not available ORA-01092 ORACLE instance terminated. Disconnection forced ORA-03113 end-of-file on communication channel Other errors: -1 and 'Error Database disconnected' = dbh has been disconnected -- Kyle Oppenheim Tellme Networks, Inc. http://www.tellme.com
Re: sql-relay
> What problem is that? I don't think there's much you can do beyond > re-connecting, which Apache::DBI does. Well, the thing about SQLRelay is that it pools database connections, which is good when you want to have plenty of persistent connections to different databases. My only problem with it is that it doesn't seem to support prepared_cached statements... Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: sql-relay
Richard Clarke wrote: > I mean in the case of the database crashing and being able to switch > to a replicated backup system. That's trivial to implement if it happens during connect time. You can simply keep a list of databases to try, and if one fails you go on to the next. This approach is compatible with Apache::DBI, which will check database handles before handing them out to you. It will attempt a re-connect, and if it fails it will pass the failure message back to you just as if it were a normal connection attempt. It's harder if you want every query to be able to automatically retry on another database if it fails. For that, you would need to add some extra code to catch the exception, recognize it as a connection failure, make a new connection, and retry the query. I don't see anything on the SQL-Relay pages about this sort of ability. - Perrin
Re: sql-relay
Perrin Harkins wrote: > Richard Clarke wrote: > >>I came across http://www.firstworks.com/sqlrelay.html the other >> day. Have any of you come across this product before. > > > It's been discussed here before (see the archives) but no one has > talked about any real experience with it yet. Try it out and tell us > what you find. > > > With the whole problem > >> of providing seemless recovery at the "client" side from database >> failure this tool seems quite productive. > > > What problem is that? I don't think there's much you can do beyond > re-connecting, which Apache::DBI does. I mean in the case of the database crashing and being able to switch to a replicated backup system. > > - Perrin > > >
Re: sql-relay
Richard Clarke wrote: >I came across http://www.firstworks.com/sqlrelay.html the other day. > Have any of you come across this product before. It's been discussed here before (see the archives) but no one has talked about any real experience with it yet. Try it out and tell us what you find. > With the whole problem > of providing seemless recovery at the "client" side from database > failure this tool seems quite productive. What problem is that? I don't think there's much you can do beyond re-connecting, which Apache::DBI does. - Perrin
sql-relay
List, I came across http://www.firstworks.com/sqlrelay.html the other day. Have any of you come across this product before. With the whole problem of providing seemless recovery at the "client" side from database failure this tool seems quite productive. I've not used it but figured maybe one of you has? Richard
