Igor Tandetnik <itandetnik-fh9draxc...@public.gmane.org> writes: > All parties in that discussion are mostly wrong.
Wonderful. Even though I was hoping they'd turn out to be correct, the actual behavior of my program was not agreeing with them. > Either that, or handle errors that come from SQLite. That turns out to be rather difficult when isolated by the JDBC driver, which has no pluggable callback to handle either the "busy" or "locked" condition. It merely hard-codes the busy timeout at 3000 ms.¹ Instead, it throws a SQLException, and the best one could do is catch the exception, inspect its corresponding message, and compare it against the string "database table is locked" -- which is obviously brittle. > Note that the stated purpose of shared-cache mode is not to improve > concurrency, but to "significantly reduce the quantity of memory and > IO required by the system." I'd like to understand that better so as to figure out whether using shared-cache mode is appropriate for my application. My motive had been increased concurrency due to finer-grained locking, but given that this part of my application is focused solely on writing in batches, which multiple threads looking to write to different tables concurrently, your response thus far says that shared-cache mode isn't going to help with that contention. Footnotes: ¹ http://code.google.com/p/sqlite-jdbc/source/browse/src/main/java/org/sqlite/Conn.java (line 143) -- Steven E. Harris _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
