Re: Oracle ping
On Nov 5, 2012, at 5:52 AM, John Scoles byter...@hotmail.com wrote: Does it automatically reconnect? That certainly seems like the wrong thing to do, especially in light of the docs for connect_cached. got that from the MySql doc it can be set up to reconnect if ping fails http://dev.mysql.com/doc/connector-python/en/myconnpy_MySQLConnection_ping.html not didn't check the DBD driver to see if it does this though. DBIx::Connector kills that option. https://github.com/theory/dbix-connector/blob/master/lib/DBIx/Connector/Driver/mysql.pm#L8 Best, David
Re: Oracle ping
On Nov 5, 2012, at 8:57 AM, Greg Sabino Mullane g...@turnstep.com wrote: Ah, so Oracle still requires an actual table? Thought they might have joined the rest of us by now in allowing things like 'SELECT 2+2;' :) No, it always requires a FROM clause, which is typically `FROM dual` for stuff like this. Best, David
Re: Oracle ping
On Nov 5, 2012, at 7:59 AM, Martin J. Evans martin.ev...@easysoft.com wrote: Just to reiterate what I eventually said. I don't want ping changed in DBD::Oracle. All I was saying is you should only read anything useful into ping returning false and not true unless your only purpose is like Oracle's OCIPing which checks your connection is still there (although not usable for some things). I believe the connection caching only does anything when ping returns false. Hrm. Well I wonder if I *should* just use DBI-ping in DBIx::Connector for Oracle rather than `select 1 from dual`. Or perhaps make it an option to switch to the select statement. Thoughts? David
RE: Oracle ping
Well I made that ping patch for DBIx::Connector a few months ago on one of my production boxes with no impact but then again I am not doing anything fancy (no rac raid etc). If it is critical to DBDx::Connector to ensure a query can be run then no, if you are going for 100% work alike betweeen all DBDs then no again and I am sure H.Merijn would like that. An option would be nice as well Cheers John Subject: Re: Oracle ping From: da...@justatheory.com Date: Mon, 5 Nov 2012 10:26:52 -0800 CC: c...@cam.ac.uk; dbi-dev@perl.org To: martin.ev...@easysoft.com On Nov 5, 2012, at 7:59 AM, Martin J. Evans martin.ev...@easysoft.com wrote: Just to reiterate what I eventually said. I don't want ping changed in DBD::Oracle. All I was saying is you should only read anything useful into ping returning false and not true unless your only purpose is like Oracle's OCIPing which checks your connection is still there (although not usable for some things). I believe the connection caching only does anything when ping returns false. Hrm. Well I wonder if I *should* just use DBI-ping in DBIx::Connector for Oracle rather than `select 1 from dual`. Or perhaps make it an option to switch to the select statement. Thoughts? David
Re: Oracle ping
On Nov 9, 2012, at 4:13 AM, John Scoles byter...@hotmail.com wrote: Well I made that ping patch for DBIx::Connector a few months ago on one of my production boxes with no impact but then again I am not doing anything fancy (no rac raid etc). If it is critical to DBDx::Connector to ensure a query can be run then no, if you are going for 100% work alike betweeen all DBDs then no again and I am sure H.Merijn would like that. An option would be nice as well At this point, I'm inclined to leave it as is. Why? Because one of the advantages of DBIx::Connector is fixup mode. Use that mode, and ping will only be called by txn() and friends only in the event of a failure. Which means that its overhead goes away, for the most part, no matter how it's implemented. So yeah, it's slower, but use fixup mode and avoid it altogether. Best, David
