oracle rdbms connector

Cantor, Scott cantor.2 at osu.edu
Thu May 23 16:03:08 EDT 2013


On 5/23/13 2:14 PM, "Roderick Grau" <rgrau at albany.edu> wrote:
>
>I removed the container manager connection from idp2.xml and altered the
>data connector to be an application managed connection.

I wouldn't expect that to help if the problem is the driver's connection
behavior.

>The idea is to failover to the static connector during DB
>reboots/patching and then have the primary data connector come back once
>the DB is back.  This is a very low usage SP so the lack of sending data
>via the static connector is not an issue.

Yes, that's not an uncommon approach, but it again assumes reasonable
connection behavior from the driver, or it will just hang the same as
before. It can't failover if it never gets control back.

I had issues similar to yours with Sybase. I tried for weeks and nothing
worked. You can't fix a broken driver. If it doesn't time out predictably,
there's no way you can or should use the IdP with it.

>I tested the config by having the DBAs down the DB, but the IDP is still
>trying to connect to the primary connector and not failing over.

It's always going to try, on every single request. That doesn't prevent it
from failing over unless the "try" hangs.

The old IdP used to have the concept of "dead" connectors that it would
treat as out of service, but I don't recall that being there anymore, and
I don't see it in the code.

If you don't see it coming back, reporting an error, and logging that it's
failing over to the static connector, then you can be certain it is simply
hung waiting for your driver to return to it with an error.

>Is the poolBreakAfterAcquireFailure="true" making the failover not happen
>or am I missing something?

I had no success with the c3p0 pooling code, so I know little about it as
a result. As far as I know if it doesn't failover, it's not getting
control back from Oracle's driver or from the pooling code. I don't know
anything about the setting you're talking about, but if it's a c3p0
option, you can check their documentation to find out what it means. Those
options should all be directly applied to that layer.

I wouldn't think it would be a good idea to use a setting like that here.
If it does what it sounds like, it would render the pool dead and might
just never try again, which is hardly useful. It would be for cases where
the backup connector was real, not static.

-- Scott




More information about the users mailing list