Reply to thread

Message: [QUOTE="alin, post: 613785"] jTDS is faster in most situations than other JDBC drivers for SQL Server and yes it was designed and refactored and tested for that. It is also becoming at least as stable as the top commercial drivers; maybe you should also test for errors. However the fact of the matter is that unless you're transferring large amounts of data to and from the server the major factor affecting performance is network latency, i.e. even if jTDS processes some response twice as fast as the MS driver, the time it will take to send the request and receive the answer from SQL Server is orders of magnitude greater than the processing time so it will make no difference whatsoever. This is not taking into account the fact that (AFAI understand) your application is a web app and there's an extra layer of network communication there. This might be stretching it a little; jTDS isn't unbeatable. It's just pretty fast; there will always be some situations in which other drivers will be marginally faster, mostly because jTDS maintains compatibility with _very_old_ SQL Server and Sybase versions and is both a JDBC 2.0 and 3.0 implementation (no other driver AFAIK will work _with_the_same_binaries_ on both Java 1.3 and 1.4 or later). But this is compared to the commercial drivers; the MS driver is a particularly bad implementation (probably so in order to convince Java programmers that Java is slow and more unstable than .Net or whatever). There's the selectMethod problem I explained in my previous post, there's the fact that prepared statements aren't actually prepared but sent again and again on each execution, there's the fact that it does pretty complex SQL parsing compared to jTDS, there's no statement caching, no real batching support and there's the undeniable fact that MS has only fixed a few dozen minor bugs in about 4 years (!) although bug reports and feature requests abound (jTDS has had a few hundred bugfixes in the same time period and a lot of new features added). But let's get over trashing the MS driver. There are a few things you should look at when setting up jTDS; all of these are at least touched in the jTDS FAQ ( [URL]http://jtds.sourceforge.net/faq.html[/URL] ). In the current (1.0.3) version you should take a look at the sendStringParametersAsUnicode property (also important with other SQL Server drivers), prepareSQL (which controls how and if statements are prepared), maxStatement (the size of the prepared statement cache) and namedPipe (which could make a huge difference if SQL Server and the JVM are running on the same server). In the current development version (and the upcoming 1.1 release) there are properties to control how much data is cached to memory before dumping to disk in the case of concurrent statement execution, using fast forward only cursors instead of direct, firehose cursors (this should help with concurrency, but it will affect direct measured performance), newly implemented support for prepareSQL=3 (the new default, it isn't affected by transaction rollbacks) and meta data caching for prepared statements (improves performance in some extreme prepare-execute-close cases with up to 50% -- e.g. with Hibernate and rather complex result sets). As you can see, there are a lot of things you should/could look at and there's no single answer to how jTDS should be set up. We have tried to come up with some sensible defaults, that should provide good performance in most cases (and stability -- e.g. the metadata caching can break things if the schema changes so it is disabled by default). The two major things you can do are (i) enable named pipes if running on the same server (this will render timeouts useless) and/or (ii) get the current develiopment version (which is pretty stable, we're close to releasing it) and try the new changes (they are already documented in the HTML documentation). Hope this helps more than confuses. :o) Alin. [/QUOTE]

Verification