So let me know if I understand:

   1. SQLITE_THREADSAFE=0: lock are disabled at all, and you can use
      this if the application  is not multi thread, so if there's only
      one thread that can use the SQLITE library
   2. SQLITE_THREADSAFE=1: is the highest level of thread safety, so if
      the slowest mode but you do not have to care about multiple access
      to the SQLITE library from different thread. You need this in a
      multi thread application to be sure to avoid damage to the DB
   3. SQLITE_THREADSAFE=2: it's a compromise between thread safety and
      speed. The library are thread safe but you have to avoid that two
      thread can use at the same time the same DB connection. So if you
      have for example 3 thread and every thread access the library with
      it own connection there's no problem So you can use two different
      DB connection from two thread at the same time without problem. Is
      that right?


Il 05/10/2010 18.34, Jay A. Kreibich ha scritto:
> On Tue, Oct 05, 2010 at 12:44:59PM +0200, Zaher Dirkey scratched on the wall:
>> On Tue, Oct 5, 2010 at 4:55 AM, Jay A. Kreibich<j...@kreibi.ch>  wrote:
>>
>>> On Mon, Oct 04, 2010 at 07:25:05PM -0700, Dustin Sallings scratched on the
>>> wall:
>>>
>>>
>>>    The main difference between =1 and =2 is that =2 assumes you more or
>>>   less know what you're doing and will either lock a database handle as
>>>   you pass it between threads or you'll keep it private to a thread.
>>>
>>>   =1 is designed to be more or less idiot proof, and will simply not
>>>   let you do something stupid with a database handle, like have two
>>>   threads try to execute two different statements at the same time.
>>>
>> What if two therad make insert or update then commit, what is happen to the
>> second thread after the first made commit?.
>    The second thread will block if it attempts to use a database
>    connection that the first thread is already using.  Once the first
>    thread finishes (either with an explicit COMMIT/ROLLBACK, or because
>    all auto-commit transactions go out of scope) then the first thread
>    will release the database connection and the second thread will wake
>    up and allowed to proceed.  That's why the =1 mode is called "serial"...
>    it automatically serializes the database statements.
>
>    At least, I'm pretty sure that's how it works.  I generally avoid
>    threaded code, and when I do use it, I tend to use thread-specific
>    resources that are carefully locked and guarded.
>
>     -j
>


-- 
Selea s.r.l.


        Michele Pradella R&D


        SELEA s.r.l.

Via Aldo Moro 69
Italy - 46019 Cicognara (MN)
Tel +39 0375 889091
Fax +39 0375 889080
*michele.prade...@selea.com* <mailto:michele.prade...@selea.com>
*http://www.selea.com*
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to