Bob Duffy's Blobby Blog : JDBC

JDBC: When Good Prepared Statements go Bad

boduff — Sun, 11 Nov 2007 19:44:14 GMT

I've been doing some performance comparisons of JDBC from Java with ADO.Net from Dot.net. One key thing that jumps out at me is JDBC tends to make more use of prepared statement, even to the point of abusing the poor thing.

I see some mid-tier manufacturer making bland claims like "Our SQL is always perfectly optimised as its prepared". Oh very dear - wake up call - a Prepared statement like anything is something that is good in some scenarios and is bad in others, so using it for EVERTHING is folly.

ok, so what is a prepared statement in reality? Its a way for SQL Server to repeat the same SQL Statement multiple times without having to repeat the query plan and as importantly without having to send the statement down for the second and subsequent iterations. To facilitate this internally the driver will we call the stored procedure "exec sp_prepexec" to prepare the statement and return a handle to the query and then for every execution of the query we call "exec sp_execute @handle" followed by the parameters of the statement (the data). You can actually do prepared statements manually by just calling "sp_prepexec" and "sp_unprepare" although these commands are largely undocumented.

From a performance point of view a prepared statement can get similar benefits as a stored procedure. This would be great, but the whole benefit of stored procedures isn't generally to do single atomic statements anyway!

The hidden cost of Prepared Statements

Not surprisingly the hidden cost of prepared statements versus stored procedures is the fact that they need to be prepared (doh!). From a SQL Server point of view we need to allocate a variable for every single parameter, figure out the cache plan, allocate a handle to the call, etc so the first call from SQL profiler will look something like this:

declare @p1 int
set @p1=1
exec sp_prepexec @p1 output,N'@P0 nvarchar(4000),@P1 nvarchar(4000),@P2 nvarchar(4000),@P3 int,@P4 int,@P5 int,@P6 int,@P7 int,@P8 int,@P9 int,@P10 int,@P11 nvarchar(4000),@P12 float,@P13 float,@P14 float,@P15 int',N'INSERT INTO Sales.SalesOrderHeader (OrderDate,DueDate,ShipDate,Status,OnlineOrderFlag,CustomerID,ContactID,TerritoryID,BillToAddressID,

ShipToAddressID,CreditCardID,CreditCardApprovalCode,SubTotal,TaxAmt,Freight,ShipMethodID)
VALUES (@P0,@P1,@P2,@P3,@P4,@P5,@P6,@P7,@P8,@P9,@P10,@P11,@P12,@P13,@P14,@P15)
select SCOPE_IDENTITY() AS GENERATED_KEYS',N'2001-07-01T00:00:00',N'2001-07-13T00:00:00',N'2001-07-08T00:00:00',5,0,676,378,5,985,985,16281,N'105041Vi84182',

24643.9362,1971.5148999999999,616.09839999999997,5
select @p1

when we are finished we need to close the pointer to the prepared statement using "exec sp_unprepare @handle"

Now I'm going to go out on a limb here and say that this is more expensive than just executing the statement in the normal way "INSERT INTO Table1 (C) VALUES (1)", for a single call. The real benefit is on multiple calls.

Think of a prepared statement as the milli-gun in doom, takes a bit longer to spin up but when it does happy days. Not the weapon of choice for every task!

What Does a Good use of a Prepared Statement Look like

To see if your application is making good use of prepared statement you can run SQL Profiler which is install with SQL Server performance Tools. Good use of a Prepared Statement from JDBC can be seen below. We prepare once and then reuse the statement object for subsequent calls.

What Does Bad use of a Prepared Statement look like

In this example we can see that the statement is prepared once per call to SQL Server resulting in more chatter to SQL Server an no real re-use of the prepared statement.

When to NOT use prepared statements

1) When you are closing the statement after execution.

2) When you are only executing the statement once.

In a lot of development houses it is considered good practice to develop coding standards that make methods "stateless", e.g. each method opens and closed the resources that it needs and keeps it own house clean.

This renders the prepared statements useless as a tool to improve performance.

Like connection pooling we need to cache the statement object to get the benefit of re-using the prepared statement .

Providing Feedback on the Microsoft JDBC Driver

boduff — Sun, 11 Nov 2007 18:45:00 GMT

Thanks to everyone who was the the first Irish Java Developers Conferance (http://ijtc.firstport.ie). Hopefully there will be a repeat performance next year. Many people were surprised to see Microsoft at the event, I guess this is a sign of the times with software becoming more cross platform. Most customers I deal with tend to have a little bit of all technologies and the real challenge is getting them to play nice togethor.

To report a bug in Microosft JDBC driver you can log on to http://connect.microsoft.com. Any feedback here automatically gets filled as a bug in Team Foundation Server and is reviewed (triaged) at the next review (sometimes called war meeting). Contrary to popular belief it does not get made into a paper plane and filed into the bin!

There also a forum to get questions answered and discuss with peers, the product team listens in and can help answer questions too.
http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=87&SiteID=1

Finally if you have any feedback of suggested improvements, you can post suggestions on the new JDBC blog site:
http://blogs.msdn.com/jdbcteam/archive/2007/11/09/jdbc-driver-feature-suggestions.aspx

Fog Creek Comes to Dublin

boduff — Sat, 03 Nov 2007 13:55:00 GMT

There's a great guest speaker coming to the IJTC (Joel Spolsky) who must be one of the most famous bloggers full stop. He wil be delivering the Key Notes for the IJTC event starting on the 8th.

Even better there a raffle for a champagne reception with Joel nat 30,000 ft over the Irish Sea on route to London.

The Irish Java Technologies Conference

boduff — Mon, 29 Oct 2007 01:48:00 GMT

The Irish Java Technologies Conference is running in Parnell Cinemas from wed 7th Nov to Fri 9th November. There is some pretty heavy hitting speakers on all things to do with Java, and the venue is excellent - beer, snacks comfy chairs and you can maybe sneak in to a movie...

http://ijtc.firstport.ie/

I am fascinated by popular mid-tier caching technology and increased degree of object orientism in Java. I'm often called in the pick up the mess when implementaiton of database mid tiers flop miserably on the dot.net platform (yes I have actually seen entire tables converted to collections of serialised objects in the interest of academic data abstraction, arghhhhhhhhh its like a nightmare).

Anyways we are doing a session on optimising SQL Server for the Java Platform. I'm going to focus on general SQL Server DBEngine performance best practises, the JDBC driver and SQL Programmabiltiy features to help improve performance and productiivity. Hopefully most people will be able to pick up some tips to improve their interactivity and experience with SQL Server.

I would love to hear if anyone is currently having or has had any performance problems with Java/JDBC and SQL Server and would be willing to share experiences and discuss. If anyone is interested, drop me an email.