>> jTDS has some sort of internal caching for automatic reuse of >> PreparedStatements, but it is unclear for me what are its criteria to >> decide the reuse of a cached statement. Here is the place I had that >> hint: >> http://jtds.sourceforge.net/faq.html#preparedStatmentMemoryLeak > > I'd be curious to hear about your findings, when you find out.
I haven't found much for now, but still on the JTDS FAQ, there is this parameter: prepareSQL (default - 3 for SQL Server, 1 for Sybase) This parameter specifies the mechanism used for Prepared Statements. Value: Description 0: SQL is sent to the server each time without any preparation, literals are inserted in the SQL (slower) 1: Temporary stored procedures are created for each unique SQL statement and parameter combination (faster) 2: sp_executesql is used (fast) 3: sp_prepare and sp_cursorprepare are used in conjunction with sp_execute and sp_cursorexecute (faster, SQL Server only) I guess "3" means it is not doing a round-trip before execution as I thought, but it would be worth checking. In any case, that does not invalidate the need for plain SQL sent based on a Factory setting because (as far as I can tell) prepared statements have an additional cost that for example in my application we do not want. Hope this helps, -Christopher
