{"id":730,"date":"2005-12-02T14:27:39","date_gmt":"2005-12-02T18:27:39","guid":{"rendered":"http:\/\/wordpress.cephas.net\/?p=730"},"modified":"2014-04-23T05:29:31","modified_gmt":"2014-04-23T13:29:31","slug":"java-jtds-preparedstatement-and-varchar","status":"publish","type":"post","link":"https:\/\/cephas.net\/blog\/2005\/12\/02\/java-jtds-preparedstatement-and-varchar\/","title":{"rendered":"Java, JTDS, PreparedStatement and varchar"},"content":{"rendered":"

I’ve been working on an interesting application at work that needs to be fast, the faster the better in fact. I wrote a couple quick and dirty implementations in my scratchpad in Eclipse and I figured that I could get about fifty operations per second (a database UPDATE is involved for every operation among other things). Anyway, I went to develop a full implementation and a then ran a full test of about 100,000 operations. Instead of taking about 30 minutes (100,000 operations \/ 50 per second = ~ 30 minutes) the operation took about 7 hours. I was getting about 4 operations per second throughput, which was obviously a huge disappointment. The pseudocode I wrote originally looked something like this:
\n
\nConnection c = DriverManager.getConnection(cs);
\nString q = \"UPDATE mytable SET x = 1 WHERE id = ?\";
\nPreparedStatement p = c.prepareStatement(q);
\nfor (int i=0; i
\n<\/code>
\nand it worked well. I made a single change during development: instead of using the ‘id ‘ column of the database table (a numeric 9 byte primary key and thus is the clustered index for the table) I used a 13 byte varchar column as the identifier which had a nonclustered index, my code looked like this:
\n
\nConnection c = DriverManager.getConnection(cs);
\nString q = \"UPDATE mytable SET x = 1 WHERE y = ?\";
\nPreparedStatement p = c.prepareStatement(q);
\nfor (int i=0; i
\n<\/code>
\nThe nonclustered index performed just as well as the clustered index: in my testing an UPDATE statement using the varchar column as the constraint in the query worked just as fast as the primary key \/ clustered index, which makes sense because index seeks (which I learned about in my database design<\/a> class this semester) on a 9 byte \/ 72 bit numeric value (because I used a precision of 19 digits<\/a>) should be similar to index seeks on a 13 byte \/ 104 bit varchar column. So then I executed the finished program (not the test) and brought up SQL Profiler<\/a> (a tool that ships with SQL Server that can debug, troubleshoot, monitor, and measure your application’s SQL statements and stored procedures). It quickly became clear what the problem was. Here’s the SQL created by the prepareStatement() method:
\n
\ncreate proc #jtds000001 @P0 varchar(4000) as UPDATE mytable SET x = 1 WHERE y = @P0
\n<\/code>
\nand then the executeUpdate()<\/code> method:
\n
\nexec #jtds000001 N'005QDUKS1MG8K'
\n<\/code>
\nSee the problem? The JTDS driver<\/a> turned the 13 byte varchar column into a 4000 byte varchar column (the maximum number of bytes for a column) and then prefixed the parameter with ‘n’, which is used to identify Unicode data types<\/a>. This substitution caused the query processor to ignore the index on ‘y’ and do an index scan instead of an index seek. <\/p>\n

Here’s where is gets fun. Microsoft SQL Server uses a B-tree index structure<\/a> (also on wikipedia<\/a>), which is similar to a B+tree<\/a>, except that search key values can only appear once in the tree. Objects are stored in SQL Server as a collection of 8KB pages and (because of the class I’ve been taking) I now know that you can compute the approximate number of disk IO’s for an index seek as:
\n
\nlogn\/2<\/sub>(k)
\n<\/code>
\nwhere n is the number of keys per node and k is the number of search keys. So with one million search keys and 8KB pages in SQL Server, a index on a 13 byte key would create a tree with about 615 nodes (~8000 \/ 13 = ~615). Thus the index seek in my system was costing about log615\/2<\/sub>(1000000) = 2.4 node accesses (one node access ~= one disk IO) versus an index scan (615 nodes @ 8KB each, figure that on average over time we’ll find the value in 615\/2 so ~307 node accesses?) which is significantly longer and obviously the cause of the problem.<\/p>\n

Moral of the story: watch out for char \/ varchar constraint parameters when using JTDS and a PreparedStatement. Also, indexes are A Good ThingTM<\/sup>.<\/p>\n

Updated 12\/04\/2005: Brian Heineman<\/a> (one of the maintainers of the JTDS project) points out that this is a feature, not a bug. He also points out that you can work around the issue by appending:
\n
\nsendStringParametersAsUnicode=false;
\n<\/code>
\nto your database connection string (I tested it out and it works just as advertised). Since the real issue is that JTDS can’t tell if the String instance I’m sending is Unicode or not and so defaults to a Unicode string, the other workaround would be to use the setBytes() method of the PreparedStatement and the use the byte[] representation of the String. From my example above:
\n
\np.setBytes(1, somearray[i].getBytes());
\n<\/code>
\n<\/font><\/p>\n","protected":false},"excerpt":{"rendered":"

I’ve been working on an interesting application at work that needs to be fast, the faster the better in fact. I wrote a couple quick and dirty implementations in my scratchpad in Eclipse and I figured that I could get about fifty operations per second (a database UPDATE is involved for every operation among other … Continue reading Java, JTDS, PreparedStatement and varchar<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[3,2],"tags":[],"_links":{"self":[{"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/posts\/730"}],"collection":[{"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/comments?post=730"}],"version-history":[{"count":1,"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/posts\/730\/revisions"}],"predecessor-version":[{"id":1841,"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/posts\/730\/revisions\/1841"}],"wp:attachment":[{"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/media?parent=730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/categories?post=730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cephas.net\/blog\/wp-json\/wp\/v2\/tags?post=730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}