Discussions

News: The SQL Server Team has released a new JDBC Driver for SQL Server

  1. Microsoft SQL Server today announced the general availability of the SQL Server 2005 JDBC v1.2 driver has been released. This release continues Microsoft's commitment to the Java community and non-Microsoft centric programming platforms. The driver can be found at http://msdn.microsoft.com/data/jdbc. In this release, we have re-architected the communication stack resulting in significant performance and scalability improvements, as well as minimizing the driver memory footprint usage. This is especially true with multiple active connections and result sets. The new driver also has improved streaming capabilities. These enhancements are most visible when the "responseBuffering=adaptive" connection property is used. As part of Microsoft’s continual commitment to security, the new driver supports SQL Server SSL encryption. The driver also introduced a new global tightly coupled XA transaction ID support when used with the following hotfix for the Microsoft DTC component http://support.microsoft.com/kb/938653. The SQL Server JDBC team continually monitors TheServerSide threads and would love to get your feedback on the driver for future releases as well as areas where we can help improve Java/JDBC connectivity to SQL Server, so do let us know what you think?
  2. I recently worked on a project that runs on SQL Server and Hibernate 3. I'm sure the teams looks forward to trying out your driver and thanks you for your effort.
  3. Just wondering, how does your driver compare with the JTDS open source driver? Any benchmarks, or even feature comparisons?
  4. JTDS doesn't support XA[ Go to top ]

    I can think of two major advantages of the MS driver over JTDS: 1) True XA support 2) Support for SQL2k5 mirroring (failover)
  5. Who trusts XA??[ Go to top ]

    Automatic failover would be great, but I'm not so sure about the true value of XA. Tell me one transactional container that handles this well: a) Phase-1 commit, to server A b) Phase-1 commit, to server B c) Phase-2 commit, to server A d) Phase-2 commit to server B is about to happen, but server B goes down c) and d) are supposed to happen atomically but there's always a slight lag between the two. After c) is sent, you can't roll it back anymore. All XA is is a programming convenience, for which you pay a high performance cost.
  6. I trust XA much more than without it...[ Go to top ]

    The time between steps (c) and (d) is usually much, much shorter than that between (a) and (b). For example, suppose trivial operation (a) takes 1 second and complex operation (b) takes 15 seconds. WITHOUT XA, you have a 15 second window where something could go wrong. WITH XA, it's typically mere miliseconds. Yes, there is overhead and you need to watch out for locking problems, but for some applications (i.e. banking, physical security...) it's totally worth the tradeoff.
  7. Just wondering, how does your driver compare with the JTDS open source driver? Any benchmarks, or even feature comparisons?
    I was using the Microsoft driver some years ago, then I switched IMMEDIATELY when I found jTDS, since the Microsoft one was doomed with lots of bugs. I hope that those bugs have been fixed... (I wonder how much will this post last, until it will be deleted :-) ) Antonio
  8. Most people I know who are connecting to MS SQL Server are using the jTDS driver for performance and reliability, but would be willing to consider Microsoft's driver again. Let the testing begin....
  9. Nice work guys. We've been using the 1.1 version of the SQL Server drivers and they're working a treat. Looking forward to upgrading.
  10. Given the announced retirement of J# from Visual Studio this should be a live question again :)
  11. i recently wasted a significant part of my life wrestling "true" XA off SQL SERVER only to find out that XA does *not* work if SQL SERVER (2005 in our case) runs on Windows XP (the MS JDBC driver consistently throws an exception when asked to init an XA transaction (Error: xp_sqljdbc_xa_init failure, status:0 msg:*** SQLJDBC_XA DTC_ERROR Context: xa_init, state=1)). Even with this brand-new JDBC driver, MS themselves state in their release notes ----------------- 6) XA TRANSACTION FAILURE ON WINDOWS XP XA transactions will not work if SQL Server is running on Windows XP unless the following hotfix is applied: "Performance Slows When You Use XA Transactions with SQL Server" http://support.microsoft.com/kb/318818 Note this issue only applies when the SQL Server that is participating in the XA transaction is running on Windows XP. ----------------- However, the hotfix referred to is not for XP (and anyways should have found it's way into a windows service-pack by now). In addition, the problem reported for this hotfix is not outright failure of XA. Still, they file this under "XA TRANSACTION FAILURE ON WINDOWS XP". It's all an unholy mess. Other people have also reported similar problems: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=262525&SiteID=1 At the end of this page http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rtrb_dsaccess4.html IBM describe a cracy but plausible fix which i've tried but which didn't solve the issue at all. So: i conclude XA still doesn't work if SQL SERVER runs on Windows XP - even with this new JDBC driver. From the verbosity of this posting you can deduce what an unexpected nerve-wracking experience this was. I mean: problems with XA on a RDBMS in 2007 - you must be joking...or so i thought. regards, gerald http://www.gerald-loeffler.net
  12. Thanks for the post Gerald - good to know.
  13. XA support in XP[ Go to top ]

    Sorry about this Gerard, it looks like the readme needs to be updated. You should try this hotfix for XP http://support.microsoft.com/kb/922668 If you are still getting problems, please reply to this mail. I will follow up. Mugunthan
  14. getGeneratedKeys()[ Go to top ]

    Is getGeneratedKeys() working with this new release or do we still have to issue a SELECT @@IDENTITY after an INSERT ?
  15. Re: getGeneratedKeys()[ Go to top ]

    This should work. What exact case is not working for you? Can you provide a snippet that does not work?