SQL Server JDBC (2.0 or 3.0) does not work in JBoss with Java 1.6.0_29 RRS feed

  • Question

  • After updating to 1.6.0_29 I am unable to connect to MS SQL JDBC 2.0 or 3.0 from JBoss 4.2.2.GA InternalManagedConnectionPool. This works properly with 1.6.0_24 and 1.6.0_27. I did not try 1.6.0_28.

    The call to InternalManagerConnectionPool.createManagedConnection(Subject, ConnectionRequestInfo) never returns.

    Has anyone else had this problem?
    Tuesday, October 25, 2011 1:02 PM


All replies

  • We have exactly the same issue although then on plain tomcat 6 and 7. We are using the DBCP connection pooling together with Spring and it fails on the same above line. Really hope that either Microsoft or Oracle fix this quickly.


    Some more information from the Oracle forum:

    • Edited by renarj Tuesday, October 25, 2011 1:37 PM
    Tuesday, October 25, 2011 1:35 PM

    Reproduced the same problem by creating a basic JDBC-connection from Java. Connection hangs indefinitely until thread is stopped.

    Problem occurs with combination of

     - SQL driver 2.0
     - SQL driver 3.0
     - SQL driver 4.0 CTP 3

     - SQL server 2008R2

     - Java 1.6.0_29

    Change either SQL server version (to 2005 & 2008) or Java version (to 1.6.0_27), and the problem doesn't occur anymore.

    Client / Server OS: Windows 2008R2


    Stacktrace at moment of thread stop:

        at Method) ~[na:1.6.0_29]
        at Source) ~[na:1.6.0_29]
        at ~[jdbc4-driver-3.0.jar:na]
        at ~[jdbc4-driver-3.0.jar:na]
        at ~[jdbc4-driver-3.0.jar:na]
        at ~[jdbc4-driver-3.0.jar:na]
        at$1ConnectionCommand.doExecute( ~[jdbc4-driver-3.0.jar:na]
        at ~[jdbc4-driver-3.0.jar:na]
        at ~[jdbc4-driver-3.0.jar:na]
        at ~[jdbc4-driver-3.0.jar:na]
        at ~[jdbc4-driver-3.0.jar:na]
        at$000( ~[jdbc4-driver-3.0.jar:na]
        at$LogonCommand.doExecute( ~[jdbc4-driver-3.0.jar:na]
        at ~[jdbc4-driver-3.0.jar:na]
        at ~[jdbc4-driver-3.0.jar:na]
        at ~[jdbc4-driver-3.0.jar:na]
        at ~[jdbc4-driver-3.0.jar:na]
        at ~[jdbc4-driver-3.0.jar:na]
        at ~[jdbc4-driver-3.0.jar:na]
        at java.sql.DriverManager.getConnection(Unknown Source) ~[na:1.6.0_29]
        at java.sql.DriverManager.getConnection(Unknown Source) ~[na:1.6.0_29]

    Crossposted on
    Tuesday, October 25, 2011 2:36 PM
  • Hello Niels,

    If you get a useful answer on the Oracle forums, please, could you share it in this thread ? ( it could be useful for visitors having the szme problem )

    Thanks beforehand and have a nice day

    Mark Post as helpful if it provides any help.Otherwise,leave it as it is.
    Tuesday, October 25, 2011 7:36 PM
  • Submitted to Java Bug database . Expected to be published at 26-10-2011.
    Wednesday, October 26, 2011 9:01 AM
  • Even though this problem is caused by a bug in Java, it also points out a vulnerability in the SQL JDBC driver. Even though the Java bug causes authentication to loop infinitely, the driver should time this out.

    It seems the loginTimeout parameter in SQL server is used only for timing out on acquiring a socket, but a connection is only useable after successful login, and as such, the loginTimeout should include the authentication process, which it doesn't, and should be considered a bug.

    So even though a socket is acquired,  the authentication step gets into an infinite loop, and should (at least) be broken out of that by the loginTimeout, resulting in an exception.

    Thursday, October 27, 2011 9:00 AM
  • This looks to be more widespread than just a MS SQL 2008 issue. I have a 2005 instance that is also experiencing the same issues. Rolling Java update 29 back to a previous version fixes the issue. 

    Here are the 2 versions that I have confirmed this bug on:

    MSSQL Version: 10.0.2531.0 Standard Edition (64-bit) OS Version: 6.1.7600

    MSSQL Version 9.00.4053.00 Express Edition OS Version:     6.0.6002 


    Here is a version that I confirmed works with update 29 of Java 6:

    MSSQL Version 9.00.1406.00 Developer Edition        OS Version: 5.1.2600 

    Thursday, October 27, 2011 5:29 PM
  • Apparently, this is related to SSL use and can be mitigated by replacing the jsse.jar in the jre/lib with that from an earlier version, for instance out of the 1.6.0_27 release. I've been confused by 1.6.0_29 working with MS JDBC and older SQL Server '05 setups which are not doing secure connections. All the newer servers (SQL Server '08 R2) fail as they require SSL and Java 1.6.0_29 does not work using jTDS or MS JDBC in this case.
    Thursday, October 27, 2011 7:45 PM
  • Hi lerdav,

    The Microsoft JDBC Driver supports Java version 5.0 and Java version 6.0. However, there is a known issue with Java 6.0 update 29 causing connection failures. Java released an early access (non-production) version of Java 6 update 30 b12 on Friday November 18, 2011. Microsoft has not yet verified Java 6u30 b12 with respect to the connection failures. Suggest you to use Java 6u27 until the problem is already fixed.

    Please follow:


    Best Regards,
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    • Proposed as answer by Iric WenModerator Thursday, November 3, 2011 6:34 AM
    • Marked as answer by lerdav Thursday, November 3, 2011 7:59 PM
    • Edited by Iric WenModerator Wednesday, November 23, 2011 2:20 AM
    Thursday, November 3, 2011 6:19 AM
  • I am pretty sure this is caused by the SSL/TLS BEAST Fix (the so called 1:n split for initial reads).

    This happens for jTDS and Microsoft Driver (with different exceptions, see below). The Microsoft Driver is using SSL for the Login in all cases (cannot be turned off). The later data connection can be encrypted or not (depending on the encrypt=true|false setting).

    If you use jTDS you can specify "ssl=off" and no SSL will be tried, not even for the Login. If the server is configured to "force encrpytion" it will not work with that.

    Instead of installing a old SSL library (or using an pre-U29 JRE) you can specify the following java system property, it will switch off the BEAST SSL fix in Oracle Java: -Djsse.enableCBCProtection=false

    I wrote a (german) blog article about this issue and reported the Bug to the jTDS developers:

    BTW: Java 6 Update 30 does not contain a fix for this.

    Bernd (german)
    Sunday, January 1, 2012 4:08 AM
  • Microsoft is releasing a patch that will enable SQL Server to work with Java 6 update 30 and up.  See this blog for more details. 


    Note that this is a SQL Server patch that you can obtain by upgrading to the service pack & cumulative update for your SQL Server version as mentioned in the blog.


    We look forward to your feedback.

    Tuesday, January 24, 2012 9:56 PM
  • Microsoft now has a patch available for SQL Server and Java 6 update 30 and above to address the issue noted in this post.


    See the following blog post for more details.

    • Proposed as answer by dpblogs Tuesday, January 24, 2012 10:02 PM
    Tuesday, January 24, 2012 10:02 PM
  • This blog post is no longer available.   I went out to the SQL Server web page and none of the udpates out there are current.   Please reply back with how we can proceed with resolving this problem.

    Thank you

    Thursday, February 16, 2012 5:25 PM
  • I just tested connecting to SQL Server 2005 and SQL Server 2008 R2 using Java 1.7.0_03 (the latest update available) and setting ssl=require in the JDBC URL.  I am using the jTDS 1.2.4 driver.

    The result is the same: the connection is reset by SQL Server and no connection is possible.

    I have to echo ChrisG1971's question: is there any fix for this problem?  Again, the blog post listed above is no longer available.  This is a pretty urgent problem, as we have a lot of customers that are anxious to update their Java, but cannot do so until SSL is available.

    • Edited by The-Edge Tuesday, February 28, 2012 11:54 PM
    Tuesday, February 28, 2012 11:50 PM
  • (The-Edge) There is a workaround for this, by replacing the jre/lib/security/jsse.jar from a JDK that is at least 2 levels back from where we are currently at with 1.6.0_30.  I am not sure about 1.7. 

    This is very strange, Oracle insists it's a Microsoft issue.   I guess the only option is to pursue this with Microsoft support directly.

    Wednesday, February 29, 2012 5:17 PM