JPA: How to resolve the “java.sql.SQLException: Io exception: Size Data Unit (SDU) mismatch” error in Java/JEE/JPA

I was developing a JPA JEE application were this strange and vague error appeared and stopped me from storing OrderHeader/OrderItem POJO’s.

Internal Exception: java.sql.SQLException: Io exception: Size Data Unit (SDU) mismatch.

This SDU error is rather vague and does not reveal the true problem in the executed SQL or Schema or constraint violation!
After many trials, here is the way I was able to identify the real Oracle DB error !

1. Take the OrderHeader/OrderItems classes into a new JSE batch project.
2. in NB , right-click –> insert code–> Persist EntityClass
3. Add the following properties to “persistence.xml” for more detailed logging:

<properties>
 <property name="toplink.logging.level" value="FINEST"/>
 <property name="eclipselink.logging.parameters" value="true"/>
 </properties>

After the previous update you should be able to see in the Glassfish logs, all the executed SQL’s and even their bind variables.

<pre>Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.5.0.v20130507-3faac2b): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLException: Io exception: Size Data Unit (SDU) mismatch
Error Code: 17002
Call: INSERT INTO XYZ (x , y, z) values (?,?,?)
 bind => [655, 5, 62]
Query: InsertObjectQuery(zyx.entity.TocOrderItem[ ])
 at org.eclipse.persistence.exceptions.DatabaseException.sqlException(DatabaseException.java:340)
 at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.processExceptionForCommError(DatabaseAccessor.java:1605)
 at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeDirectNoSelect(DatabaseAccessor.java:893)
 at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeNoSelect(DatabaseAccessor.java:957)
 at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.basicExecuteCall(DatabaseAccessor.java:630)
 at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.executeCall(DatabaseAccessor.java:558)
 at org.eclipse.persistence.internal.sessions.AbstractSession.basicExecuteCall(AbstractSession.java:1995)
...
Caused by: oracle.net.ns.NetException: Size Data Unit (SDU) mismatch
at oracle.net.ns.Packet.receive(Packet.java:264)
at oracle.net.ns.DataPacket.receive(DataPacket.java:92)
at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:172)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:117)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:92)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:77)
at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1034)
at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1010)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:588)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:194)
at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:953)
... 97 more

And now run the new batch project and you will see the (ORA-) error clearly.  Mine was related to some XMLType / Oracle Fields in the records I want to save (out of scope).

The problem as it seems to be : that the EJB Container shields and wraps some of the returned error codes and connections; this produces the vague SDU error. The solution uses the good-old-normal JSE not JEE  JVM which will allow a more interaction between your program and JDBC.

Java Troubleshooting: Application running inside Glassfish, unable to call a webservice

Flash Forward:  3 days already trying to troubleshooting the java code for “PrivilegedActionException” Exception , it turns out it is one parameter in Glassfish that needs to be properly adjusted.

Lets go back from the beginning: 3 days ago I was writing a JEE enterprise applciation , simply  a webpage that retrieves data from a DB2 database and then based on a user’s choice it call a webservice for some of the records in the result-set.

I followed GlassFish-Developer’s-guide to call an WS-RPC webservice. the server providing this WS-RPC is somewhere located inside our enterprise network.

Read more »