On Tuesday, 22 January, 2013 19:14 MST, Ward Willats <sqlite-us...@wardco.com> wrote: > On Jan 22, 2013, at 5:54 PM, Keith Medcalf <kmedc...@dessus.com> wrote: >> In my case, I only have one writer (I think!) during the big transaction, >> so a long-lived, singleton connection or WAL should work for me. I guess I >> would lean toward the former (KISS).
Just one additional comment -- if you do the same usage counting on the writer connection when it is opened/closed by the wrapper, you can ensure that only one set of updates is in progress at a time and it may be very helpful if you are ever requested to add such a "feature" (for example, you could re-queue overlapping updates to be processed after the current update transaction is properly completed to make sure that independent updates don't get mixed up with your long transaction and perhaps rolled back in error). This could be as simple as only returning the actual connection handle when the usage count transitions 0 -> 1, otherwise return NUL so your application code knows that some other update is already in progress and to try this request again later (or tell the update source to try again later). This sort of thing may be important if your processing/request queue could look like the following: Query BEGIN Data collection Query Query Instrument Data Query Query Query Instrument Data END Data collection UPDATE Query BEGIN Data collection Instrument Data Instrument Data UPDATE Instrument Data Query ABORT data collection Query You would need to know whether the last query should see the UPDATE or not. If so, you need to ensure that it is processed only after the data collection transaction is cleared. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
