Comparison of Weblogic Multipools VS. Oracle OCI TAF?

Question

My group is thinking of going with Weblogic's Multipools as opposed to
using Oracle's TAF for failover support.
Has anyone done any benchmarking on the two - or does anyone know of
the pros and cons of going with either solution?
Any first hand feedback on either solution would be extremely helpful,
as would recommendations.
Our setup is:
Linux, oracle 9i and weblogic 7.0
thanks,
- Ryan

Answer 1

Hi Joe,
thanks for the reply - the code change helped a little. It's returning
a bit faster than it was before. However, I'm still experiencing
problems with the Multipool functionality.
After experimenting a little, I have more information on the problem
definition.
I have 2 DB Connection Pools, both set up for one multipool (set up
for HighAvailability).
I can see both pools getting populated (max of 10) at the server
startup.
DB 'getConnection' requests are being created without any problems on
the first connection pool.
As an experiment, I decided to test the health of the connection pools
frequently (every time a connection is requested). The code grabs a
connection and releases it immediately.
This is the code I wrote to do that:
>>>>>>>>>>>>>>
     try{
     conn1 = d.connect("jdbc:weblogic:pool:RConnPool1", null);
     }catch(Exception e)
     debug("Conn1 threw exception " + e.getMessage());
     finally
     try {conn1.close(); } catch (Exception e) { debug("Conn1.Close
E " + e.getMessage());}
     try{
     conn2 = d.connect("jdbc:weblogic:pool:RConnPool2", null);
     }catch(Exception e)
     debug("Conn2 threw exception " + e.getMessage());
     finally
     try {conn2.close(); } catch (Exception e) { debug("Conn2.Close
E " + e.getMessage());}
>>>>>>>>>>>>>>
That code worked inefinitely (I sent about 20-30 requests through
without problems). The actual connection being used was requestd from
the multipool right after that section of code.
>>>>>>>>>>>>>>
     conn = d.connect("jdbc:weblogic:pool:RMultiPool", null);
     notRetrieved = false;
>>>>>>>>>>>>>>
So, when I shut down one the server for ConnPool1 (through the
console), I expected to have the first try-catch to generate an
exception and the second one to continue to function healthily. I also
expected the multipool to switch over to the second pool.
On the first few requests after the db shutdown, I do get the
exception from the first Connpool1 and a healthy message from
Connpool2. However, the multipool returns exceptions for ConnPool1,
but doesn't return connections from ConnPool2 (it just throws an
exception), and healthy message from ConnPool2 stops after 10 tries,
and then I get this message:
"Error in getConnection Pool connect failed:
weblogic.common.ResourceException:
RMultiPool(RConnPool2): no connections available"
It seems that the multipool is grabbing connections from the backup
connection pool and not releasing them. I thought it was me who was
getting the connection and not releasing it, but all connection
objects I have access to appear accounted for.
I tried to confirm this by removing the multipool 'getConnection'
request (instead retrieving the connection from the second connection
pool explicity after I do the health check). With the multipool code
removed, ConnPool2 never runs out of connections.
So finally, I've implemented this bit of code:
>>>>>>>>>>>>>>
     try{
     conn1 = d.connect("jdbc:weblogic:pool:RConnPool1", null);
     notRetrieved = false;
     conn = conn1;
     }catch(Exception e)
          debug("Conn1 threw exception - FAILING OVER" + e.getMessage());
          try{
          conn2 = d.connect("jdbc:weblogic:pool:RConnPool2", null);
          notRetrieved = false;
          conn = conn2;
          }catch(Exception eX)
          debug("Conn2 threw exception - TOTAL DB FAILURE" +
eX.getMessage());
>>>>>>>>>>>>>>
And that code seems to provide failover support.. At least at the
level we need for now.
We would really rather use MultiPools - they're probably better
implemented than what I wrote above, more flexible and more of a
standard - but we just can't figure out what is preventing the
multipool from returning a good connection right away.
No. Refresh is separate. If you have testConnsOnReserve, you don't need
refresh. Set it to 99999999 to effectively turn it off and save resources.This has been changed - thanks.
I wish. However, if you get the failover URL into the pool definition,
the first pool should benefit from the oracle driver failing over internally.
If you disable a pool, using the admin command or the console, then a
multipool will quickly pass over it to the next, so if/when you know the
primary DBMS is down, you can save a lot of time for connectors, if you
disable it's pool, and re-enable it when the DBMS is back.Could you explain the paragraph above? What do you mean by the
failover URL? Do you mean I'd have to disable the connection pool
manually if the database fails? (I'm sure I'm interpreting that
incorrectly) How else can you disable and re-enable a pool
programatically and in a timely manner? Wasn't that the purpose of the
MultiPool?
Thanks,
- Ryan