Oracle 5.0 Reference Manual page 2143

second transaction, as the commit only applies to the changes made in the new connection. Rather
than a transfer taking place, a deposit was made in this example.
Note that running with
encounters a communication problem, there is no means to determine whether the server processed
the currently executing statement or not. The following theoretical states are equally possible:
• The server never received the statement, and therefore no related processing occurred on the
server.
• The server received the statement, executed it in full, but the response was not received by the
client.
If you are running with
the server when a communication exception is encountered. The statement may have reached the
server, or it may not. All you know is that communication failed at some point, before the client received
confirmation (or data) from the server. This does not only affect
the communication problem occurred during Connection.commit(), the question arises of whether
the transaction was committed on the server before the communication failed, or whether the server
received the commit request at all.
The second reason for the generation of exceptions is that transaction-scoped contextual data may be
vulnerable, for example:
• Temporary tables.
• User-defined variables.
• Server-side prepared statements.
These items are lost when a connection fails, and if the connection silently reconnects without
generating an exception, this could be detrimental to the correct execution of your application.
In summary, communication errors generate conditions that may well be unsafe for Connector/J to
simply ignore by silently reconnecting. It is necessary for the application to be notified. It is then for the
application developer to decide how to proceed in the event of connection errors and failures.
21.3.15.14: How can I use 3-byte UTF8 with Connector/J?
To use 3-byte UTF8 with Connector/J set
the connection string.
21.3.15.15: How can I use 4-byte UTF8,
To use 4-byte UTF8 with Connector/J configure the MySQL server with
character_set_server=utf8mb4. Connector/J will then use that setting as long as
characterEncoding
the character set.
21.3.15.16: Using
useServerPrepStmts=false
corruption when inserting BLOBs. How can this be avoided?
When using certain character encodings, such as SJIS, CP932, and BIG5, it is possible that BLOB
data contains characters that can be interpreted as control characters, for example, backslash, '\'. This
can lead to corrupted data when inserting BLOBs into the database. There are two things that need to
be done to avoid this:
1. Set the connection string option
2. Set to NO_BACKSLASH_ESCAPES.
SQL_MODE
Troubleshooting Connector/J Applications
enabled does not solve this problem. When Connector/J
autocommit
enabled, it is not possible to guarantee the state of data on
autocommit
characterEncoding=utf8
utf8mb4
has not been set in the connection string. This is equivalent to autodetection of
useServerPrepStmts
2123
autocommit
and set
with Connector/J?
and certain character encodings can lead to
to true.
statements though. If
useUnicode=true
in