Menu
▾
▴
#462 In MySQL Sharding environment, reconnecting with the same client after the client connection is closed then querying returns unexpected results
I'm not sure whether this issue is a bug or not. Let me explain the scenario.
I'm trying to connect to and query a CUBRID SHARD Broker using node-cubrid 2.0.0. One difference is that I have configured MySQL as a back-end database. This shouldn't matter.
Since CAS_MYSQL establishes a connection with the MySQL Server, it is possible that the established connection may expire, etc. In such case, CUBRID SHARD returns this error: *2006:MySQL server has gone away*.
In such case, node-cubrid still keeps the connection, though it's kind of useless.
So, I've created a sample Node.js app (see the attachment). What it does is once node-cubrid successfully establishes a connection with the SHARD Broker, it tries to query the SHARD with id=1. Very simple. If an error occurs, the last callback for EVENT_ERROR is called. In that error callback I first disconnect the current client, then try to connect again with the same client (i.e. I don't call createCUBRIDConnection again).
So, what I do is:
*Scenario 1*:
1. Run the program.
2. Establish a connection.
3. Query something.
4. Querying fails, and I get the expected *2006:MySQL server has gone* error.
5. If that was the error, I try to reconnect and query again. If not, just close the connection.
6. When reconnecting, it correctly establishes a connection.
7. I try to rerun the query, but it gives me the same error all over again.
*Scenario 2*:
1~4. Same as above.
5. In any error I just close the connection which closes the program.
6. I rerun the program. It correctly establishes a connection.
7. I run the query, and this time I get the results because at the backend CUBRID SHARD has reestablished the connection.
Now, the question is *why in the first scenario when I reconnect and try to rerun the query it returns the error?*
The expected result is to have the same behavior as in the second scenario, i.e. first fail, then on the second connection, get the results. But the scenario 1 doesn't work as expected.
