Alexander,
>From http://www.sqlite.org/c3ref/busy_handler.html
"The presence of a busy handler does not guarantee that it will be
invoked when there is lock contention. If SQLite determines that
invoking the busy handler could result in a deadlock, it will go ahead
and return SQLITE_BUSY or SQLITE_IOERR_BLOCKED instead of invoking the
busy handler. Consider a scenario where one process is holding a read
lock that it is trying to promote to a reserved lock and a second
process is holding a reserved lock that it is trying to promote to an
exclusive lock. The first process cannot proceed because it is blocked
by the second and the second process cannot proceed because it is
blocked by the first. If both processes invoke the busy handlers,
neither will make any progress. Therefore, SQLite returns SQLITE_BUSY
for the first process, hoping that this will induce the first process
to release its read lock and allow the second process to proceed"
Rgds,
Simon
2008/4/24 Alexander Batyrshin <[EMAIL PROTECTED]>:
> 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
> >
>
>
>
> --
> Alexander Batyrshin aka bash
> bash = Biomechanica Artificial Sabotage Humanoid
> _______________________________________________
>
> 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
