Yea, obviously the failover is done by the driver. GF is completely ignorant of the failover, it just sees a JDBC driver.
The question becomes when and where does the driver actually detect and affect change due to failover?
Arguably, the time and place to do that is when a connection is made, so that new connections will be routed to the new server, rather than perhaps having an existing connection failover.
The logic behind that is that the connection can (most likely) only safely fail over outside of a transaction. But that begs the question of whether the driver actually "knows" it's within a transaction. It could easily not "know" this, since most drivers are simply protocol proxies to the database. The DB "knows" about the transaction, of course, but the driver may well not.
So, for safety, the driver may well not be able to fail over an active connection, instead simply flailing and thrashing and yelling at the host program that the connection is bad and you should get a new one.
Now, IF (big IF) that is what is happening, then when working with a connection pool (who's sole purpose is to actually limit the number of connections made), the connection pool needs to know when a connection is "bad" so it can refresh and create a new one.
That's what the connection validation does. The "table" mode basically issues a "select count(*) from table" (or something similar) every time a connection is requested from the pool. This validates that the connection is "good". If that SQL fails, then it dumps the connection and creates a new one, which, in theory, should give you a new connection from the driver, which should have failed over. (Make it a point to use an empty dummy table for your "table" mode validation, running select count(*) on some large nasty thing would be...nasty.)
Anyway, what would probably be most useful would for you to create a simple test program, outside of the container, simply using the JDBC driver as is, and see if you can get that to work with failover. Then you can narrow down whether it's a config issue with the driver or your servers, or an actual problem with the container. You can also better understand and exercise the failover to understand whether failover happens within the same connection, or whether you need a new connection to get failover. (If the driver "knows" you're not in a transaction, it may well be able to failover an existing connection.)
But I think it's worthwhile due diligence to better understand exactly what happens with regards to this so you can better anticipate problems within your code, and a small test program, outside of the container, is your best bet to figure that out.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=292650