This discussion is archived
8 Replies Latest reply: Jan 30, 2013 4:23 PM by dsurber RSS

java.sql.SQLException: Protocol violation: [6, 7, 21, 7, 21, 7, 21, 7, 21,

marcin_30 Newbie
Currently Being Moderated
Hi

I've application running on:
- Solaris 10 64 bit
- Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_28-b04)
Java HotSpot(TM) Server VM (build 1.5.0_28-b04, mixed mode)
- jvm options"-Xms1024m -Xmx1536m -XX:MaxPermSize=128m -Duser.language=en -Duser.country=AU -XX:-UseVMInterruptibleIO"
- Oracle DBMS version 10.2.0.4.0 (64 bit)
- ojdbc version 11.2.0.3.0
And get the following exception:
java.sql.SQLException: Protocol violation: [6, 7, 21, 7, 21, 7, 21, 7, 21, 7, 21, 7, 21, 7, 21, 7, 21, 7, 54]
     at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:464)
     at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:192)
     at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:531)
     at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:207)
     at oracle.jdbc.driver.T4CPreparedStatement.fetch(T4CPreparedStatement.java:1112)
     at oracle.jdbc.driver.OracleResultSetImpl.close_or_fetch_from_next(OracleResultSetImpl.java:373)
     at oracle.jdbc.driver.OracleResultSetImpl.next(OracleResultSetImpl.java:277)

I've read many posts and have found that it can be solaris issue because there are some problems when we are using 32 bit java on Solaris 10 64 bit machine. And the proposed solution is to use additional -d64 option in jvm. Is this the correct solution? Or there are some other soluions?
Regards Marcin.
  • 1. Re: java.sql.SQLException: Protocol violation: [6, 7, 21, 7, 21, 7, 21, 7, 21,
    rp0428 Guru
    Currently Being Moderated
    Welcome to the forum!
    >
    And get the following exception:
    java.sql.SQLException: Protocol violation: [6, 7, 21, 7, 21, 7, 21, 7, 21, 7, 21, 7, 21, 7, 21, 7, 21, 7, 54]
    . . .
    I've read many posts and have found that it can be solaris issue because there are some problems when we are using 32 bit java on Solaris 10 64 bit machine. And the proposed solution is to use additional -d64 option in jvm. Is this the correct solution? Or there are some other soluions?
    >
    Before you start with solutions you have to find out what the problem is. A protocol violation exception can be caused by a lot of things. Even something as simple as the account you are connecting to being locked or expired. That doesn't appear to be you issue.
    >
    at oracle.jdbc.driver.OracleResultSetImpl.next(OracleResultSetImpl.java:277)
    >
    If what you posted is the full stacktrace the above line seems to indicate that the problem occurs when you try to iterate the result set.

    1. Can you connect without a problem?
    2. Does other Java code or connections to other accounts give an error or do they work ok?
    3. Have you tried the SCOTT schema to see if you can connect and access data?
    4. Does the error occur on the first '.next' operatoin or on a subsequent one?

    You need to do some more troubleshooting to try to isolate the exact problem and then post the code you are using.
  • 2. Re: java.sql.SQLException: Protocol violation: [6, 7, 21, 7, 21, 7, 21, 7, 21,
    EJP Guru
    Currently Being Moderated
    - Oracle DBMS version 10.2.0.4.0 (64 bit)
    - ojdbc version 11.2.0.3.0
    I'm no Oracle expert but this looks like a version mismatch to me.
  • 3. Re: java.sql.SQLException: Protocol violation: [6, 7, 21, 7, 21, 7, 21, 7, 21,
    dsurber Explorer
    Currently Being Moderated
    EJP wrote:
    - Oracle DBMS version 10.2.0.4.0 (64 bit)
    - ojdbc version 11.2.0.3.0
    I'm no Oracle expert but this looks like a version mismatch to me.
    It is not required that the JDBC version and the server version be the same. Indeed best practice is to use the most recent version of JDBC that supports the database. Typically that means a difference of no more than 2 in the major version numbers, though the exact support matrix is a bit more complicated. A difference of 1 is sure to be supported.

    So JDBC version 11.2.0.3.0 most definitely supports database version 10.2.0.4.0.

    There seems to be a lot of confusion about supported combinations of driver and database. Here are the rules:

    Every version of the database that is still supported when a new version of the driver is released is supported by that version of the driver. So if database 9.2.0 was supported when driver 11.2.0.3.0 was released then the 11.2.0.3.0 driver will connect to the 9.2.0 database.

    The inverse is also true. When a new version of the database is released every supported version of the driver will connect to that database. So when database 11.2.0.3.0 was released the 9.2.0 driver would connect to it. Now old drivers most likely will not support new database features, but old stuff will work.

    Best practice is to use the most recent version of the driver that supports the database in question. So if you have an 8.1.7 database you'd probably need a 10.2 driver (maybe 10.1 I don't recall when 8 was desupported.) Connecting to 8.1.7 database with an 11 driver is (probably) not supported.

    With respect to Java, the driver doesn't care what version of Java the database supports. The driver does care very much which version of Java you use to compile and run your code. The digit in the driver jar file name is the Java version that was used to compile the jar. (Older jars used two digits.) So ojdbc5.jar was compiled with JDK 1.5. You can always execute the driver with the same version of Java that was used to compile it. Generally you cannot run the driver with an older version of Java. That is you cannot use ojdbc5.jar with Java 1.4 for example. Frequently, but not always you can run the driver with a higher version of Java than was used to compile it. For example you can use ojdbc5.jar with Java 6. You won't get the latest version of the JDBC spec, but the old stuff will work just fine. However it is important to note that this isn't always supported.

    For Oracle to support something we have to test it. When the driver is released there is no way we can have tested against with a version of Java that has not yet been released. So when ojdbc5.jar was first released there was no way we could have tested it with Java 6. Because it wasn't tested it wasn't supported. Typically some time after a new version of Java is released we will test the older drivers. If it works, and it usually does, that configuration will be supported. Sometimes there are things that don't work and those will be identified as limitations. Usually subsequent patch releases will address those limitations. You can always use the driver with the same version of Java that was used to compile it. Sometimes you can use a newer version of Java than was used to compile the driver, but that isn't always supported. If the difference in version numbers is only 1, you are probably ok. More than 1 and you are probably on your own; eg don't use ojdbc5.jar with JDK 1.7.

    tl;dr: Use the most recent version of the driver that has a major version number within 2 of the database (This isn't guaranteed to be right, but it probably is). Use a version of the driver that was compiled with your Java version if possible or complied with an older version if supported. If there is no driver that satisfies both criteria your configuration is (probably) not supported.

    Douglas
  • 4. Re: java.sql.SQLException: Protocol violation: [6, 7, 21, 7, 21, 7, 21, 7, 21,
    marcin_30 Newbie
    Currently Being Moderated
    If what you posted is the full stacktrace the above line seems to indicate that the problem occurs when you try to iterate the result set.

    1. Can you connect without a problem?
    Yes I can connect to the database without problem

    2. Does other Java code or connections to other accounts give an error or do they work ok?
    Other java code works fine.

    3. Have you tried the SCOTT schema to see if you can connect and access data?
    It is on production lab so I can't check it

    4. Does the error occur on the first '.next' operatoin or on a subsequent one?
    This error occurs random . But mostly when we try to read first data. So by calling next metgod from ResultSet.

    I saw that it occurs by calling next method but in documentation I have not found what can be the reason. Desctiption was to general
  • 5. Re: java.sql.SQLException: Protocol violation: [6, 7, 21, 7, 21, 7, 21, 7, 21,
    marcin_30 Newbie
    Currently Being Moderated
    Hi Douglas

    "tl;dr: Use the most recent version of the driver that has a major version number within 2 of the database (This isn't guaranteed to be right, but it probably is). Use a version of the driver that was compiled with your Java version if possible or complied with an older version if supported. If there is no driver that satisfies both criteria your configuration is (probably) not supported."

    I see that currently used driver 11.2.0.3.0 was compiled with 1.5.0_30-b03. And in my environment I've java 1.5.0_28, i should use the previous version of driver right?
    But I've used also 11.2.0.2.0 driver and result was the same.

    Or it would be bether to use 10.2.0.4 driver ?

    Regards Marcn
  • 6. Re: java.sql.SQLException: Protocol violation: [6, 7, 21, 7, 21, 7, 21, 7, 21,
    rp0428 Guru
    Currently Being Moderated
    >
    I see that currently used driver 11.2.0.3.0 was compiled with 1.5.0_30-b03. And in my environment I've java 1.5.0_28, i should use the previous version of driver right?
    But I've used also 11.2.0.2.0 driver and result was the same.

    Or it would be bether to use 10.2.0.4 driver ?
    >
    You also mentioned this
    >
    And the proposed solution is to use additional -d64 option in jvm.
    >
    What '-d64' option are you talking about? Are you using some third-party tool for this?

    I can use the CLASSES12.JAR file and JDK 1.6 and connect to and query my Oracle 11.2.0.1.0 database but that jar file won't support the latest JDBC enhancements available in the later jar files.

    The only real CAVEAT regarding Java versions is that JDK 1.4 is not supported by the 11 drivers.

    Also, Oracle DB (11g) ships with, AND REQUIRES, JDK 1.5 for its own internal operation. This JDK version CAN NOT be upgraded or modified at all by the user and you should never attempt that. Doing so will violate any support agreement you have and possibly break your Oracle installation beyond repair.

    That only affect Java that you load into the DB; you cannot load classes or source that require Java functionality provided in later (e.g. 1.6) versions.

    That means that ANY Java you load into the DB must be 1.5 or lower.

    This is the OFFICIAL Oracle FAQ page that provides the full support matrix of DB vs. OJDBC vs. JDK.
    http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-faq-090281.html#02_02

    Read the entire FAQ but see these sections in particular

    Oracle JDBC in General
    What JDBC drivers does Oracle provide?
    . . .
    Which JDBC drivers support which versions of Oracle Database?
    . . .
    Which JDBC drivers support which versions of Javasoft's JDK?
    . . .
    Which JDBC drivers support which versions of JDBC?

    Those sections pretty much cover the ENTIRE matix of possible combinations.

    Then there is the complete list of jar files and what they are.
  • 7. Re: java.sql.SQLException: Protocol violation: [6, 7, 21, 7, 21, 7, 21, 7, 21,
    marcin_30 Newbie
    Currently Being Moderated
    What '-d64' option are you talking about? Are you using some third-party tool for this?

    No I'm using oracle sun java implementation on Solaris 64 bit machine.
    "The options -d32 and -d64 have been added to the Java launcher to specify whether the program is to be run in a 32 or 64-bit environment. On Solaris these correspond to the ILP32 and LP64 data models, respectively. Since Solaris has both a 32 and 64-bit J2SE implementation contained within the same installation of Java, you can specify either version. If neither -d32 nor -d64 is specified, the default is to run in a 32-bit environment.
    Other Java commands (javac, javadoc, etc.) will rarely need to be executed in a 64-bit environment. However, the -d32/-d64 options may be passed to these commands and then on to the Java launcher using the established -J prefix option (eg: -J-d64).
    All other platforms (Windows and Linux) contain separate 32 and 64-bit installation packages. If both packages are installed on a system, you select one or the other by adding the appropriate "bin" directory to your path. For consistency, the Java implementations on Linux accept the -d64 option. "

    Full description can be found here: http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#64bit_selection
    And I've observed this issue onlu on solaris 10. in other env i can't reproduce it.

    Regards
  • 8. Re: java.sql.SQLException: Protocol violation: [6, 7, 21, 7, 21, 7, 21, 7, 21,
    dsurber Explorer
    Currently Being Moderated
    Only the major version number matters for compatibility with the Java version. Well, the first two digits for the JDK. Java versioning is so confusing. Anyway, 11.2.0.3.0 was compiled with 1.5 and you are using 1.5 so you should use 11.2.0.3.0.

    Douglas

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points