If you are using processes you can sync them using a semaphore so that
it automatically blocks. Alternatively do not use sqlite3_exec (it is
an old interface) and instead use sqlite3_prepare ... sqlite3_step. If
you get an SQLITE_BUSY returned by sqlite3_step then pause a hundred mS
or so and try again.
If you don't use threads you can compile Sqlite without THREADSAFE and
have it run a little faster.
Alexander Batyrshin wrote:
> Oh... Nope, I am not using any thread-mechanism.
> I am using simple processes (via fork). So synchronization should be
> task for SQLite library.
>
> But right now I am confused, because my processes do not blocks on
> sqlite3_exec. They immediately report BUSY_TIMEOUT, without awaiting
> for time set by sqlite3_busy_timeout.
>
>
> On Thu, Apr 24, 2008 at 4:29 PM, John Stanton <[EMAIL PROTECTED]> wrote:
>> If it is one process I would assign a mutex to the resource (Sqlite) and
>> wait on it to get access to the resource. When the Sqlite operation is
>> complete release the mutex and the next thread will have exclusive
>> access to it.
>>
>> If you use pthreads you can use read and write locks to get concurrency
>> on reads.
>>
>> To my mind syncing on a mutex is better and simpler than polling the
>> resource using SQLITE_BUSY.
>>
>>
>>
>> Alexander Batyrshin wrote:
>> > So, you advice me, to implement synchronization inside my process by my
>> self?
>> >
>> > On Thu, Apr 24, 2008 at 3:40 PM, John Stanton <[EMAIL PROTECTED]> wrote:
>> >> You have a single shared resource, Sqlite, and you have to synchronize
>> >> access. You can use the internal locking in Sqlite and use polling or
>> >> wait on a mutex or semaphore.
>> >>
>> >>
>> >> Alexander Batyrshin wrote:
>> >> > Hello All,
>> >> >
>> >> > I am observing situation, that my concurrency process does not have
>> >> > access to SQLite database with equal probability.
>> >> >
>> >> > Here is example. I have N process that do work like this:
>> >> >
>> >> > while (1) {
>> >> > do_some_work(); // takes ~ 30 sec
>> >> > save_work_result_to_sqlite(); // takes ~ 1 sec
>> >> > }
>> >> >
>> >> > So, as you can see, these N process has concurrency access to SQLite
>> database.
>> >> > In theory in worst case, save_work_result_to_sqlite() should NOT wait
>> >> > for access to database longer than N * 1 sec.
>> >> > But in practice, some process blocks on save_work_to_sqlite() more
>> >> > than N*2 sec and dies on my SQLITE_BUSY asserts :/
>> >> >
>> >> > So, I am wondering, is there any ideas how to avoid this?
>> >> >
>> >>
>> >> _______________________________________________
>> >> sqlite-users mailing list
>> >> sqlite-users@sqlite.org
>> >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>> >>
>> >
>> >
>> >
>>
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>
>
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
