[Mono-bugs] [Bug 76494][Min] Changed - Mono.Data.SqliteClient Memory corruption when reusing connection after DELETE with named parameters

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by tekhedd at byteheaven.net.

http://bugzilla.ximian.com/show_bug.cgi?id=76494

--- shadow/76494	2005-12-12 17:36:38.000000000 -0500
+++ shadow/76494.tmp.985	2005-12-12 17:56:30.000000000 -0500
@@ -249,6 +249,52 @@
 here for reference, with explanations. 
 
 ------- Additional Comments From tekhedd at byteheaven.net  2005-12-12 17:36 -------
 Created an attachment (id=16205)
 A patch containing all of my bugfixes since submitting this bug.
 
+
+------- Additional Comments From tekhedd at byteheaven.net  2005-12-12 17:56 -------
+Sadly, this diff contains several different fixes. If I had known I
+would be fixing several bugs, I would have created some local
+branches. All of the bugs I fix only affect sqlite3.
+
+1) Fixes the memory corruption with named parameters. This corruption
+can happen with almost any named parameter transaction, and should
+probably escalate this to a "Normal" bug. While fixing this, some
+other things changed:
+
+ 1.1) Parameters are now passed using sqlite's unicode functions. This
+should make it possible to store 16-bit unicode in UNI-16 sqlite
+databases without translation.
+
+ 1.2) If named parameter strings are "long", sqlite uses a callback
+function (delegate) to free the memory, which could help performance
+with very large (ie 2-3 megabyte) string storage. (It helped me.) This
+is not done for small strings as it increases memory fragmentation and
+seriously hurts performance.
+
+2) Compiled sql is not deleted immediately after use. This allows you
+to reuse the sql command objects. You can now also reuse the command
+objects after changing the query text, as expected. Minor performance
+enhancement.
+
+3) Added code to store binary blobs. Also, the Command now looks at
+the DbType associated with a named parameter when saving it, instead
+of guessing based on the data type. Just because Sqlite makes wild
+guesses about data types doesn't mean we have to. :) Also, this is the
+only way to ensure that 
+
+4) The lock timeout code is all commented out. It works, but
+performance was so bad I gave up and only access sqlite
+single-threaded. Maybe this will be fixed in future versions of
+sqlite3, though.
+
+5) There is still code to map transaction levels to sqlite3
+transaction levels. This is very useful with multiple threads, since
+it is very easy to get in a deadlock with the default transaction
+level (and multiple threads), in which case sqlite throws an exception
+instead of blocking (even if you use a lock timeout).
+
+Ultimately, sqlite could not meet my performance needs. (That dang
+journal file is too slow on windows.) But maybe this code will help
+others.