Skip navigation links

MySQL Forums :: Connector/JDBC and Java :: loadbalance url : statement vs preparedstatement


Advanced Search

loadbalance url : statement vs preparedstatement
Posted by: murat cengiz ()
Date: December 25, 2012 03:23AM

Hi,

Is there a difference between using regular statements vs using prepared statements in regards to rebalancing behaviour of connector/j?

I execute the following:

1. get connection from driver
2. make the first host (host1) unavailable
3. execute some sql on the connection (should fail). sql="select field1 from nonexistingtable"

url: "jdbc:mysql:loadbalance://host1,host2:3306/TESTDB?autoReconnect=false&connectTimeout=5000&socketTimeout=30000&relaxAutoCommit=true&failOverReadOnly=false&characterEncoding=UTF-8"

connector/j : 5.1.18

java: 1.6.0.37

If i execute the 3rd step using regular statements, a physical connection to host2 is established. (query fails after sockettimeout ms)

But if i execute the same step using a prepared statement, no physical connections are established to host2. (query fails after sockettimeout ms)

Is there a reason why they behave differently? Is this expected behaviour?

Actually i am trying to validate the connection, and i read somewhere that the validation query should start with "/* ping */", especially for a loadbalanced configuration. Does anyone know what this "ping" query actually does?

thank you

Options: ReplyQuote


Subject Written By Posted
loadbalance url : statement vs preparedstatement murat cengiz 12/25/2012 03:23AM
Re: loadbalance url : statement vs preparedstatement Todd Farmer 12/27/2012 09:59AM
Re: loadbalance url : statement vs preparedstatement murat cengiz 12/28/2012 04:23AM
Re: loadbalance url : statement vs preparedstatement Todd Farmer 12/28/2012 11:34AM
Re: loadbalance url : statement vs preparedstatement murat cengiz 01/02/2013 07:48AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.