On Apr 24, 2008, at 7:42 AM, Alexander Batyrshin wrote: > I am not understand this example. First of all second process can't > promote exclusive lock from reserved. It should use intermediate > pending lock.
It does go to pending. But it still cannot complete the transaction until it is able to promote the pending lock to exclusive. And it cannot promote to exclusive until the first process drops its read lock. > And secondary why first process can't just drop read > lock and then invoke busy handler? Dropping the read lock is the same as rolling back the transaction. The first process can, in fact, do this. And the second process is waiting for the first process to do this. But the first process cannot do it automatically. The application must issue a "COMMIT" or "ROLLBACK" command to make it happen. > > > In this case any write to database that already has process > > On Thu, Apr 24, 2008 at 6:01 PM, Simon Davies > <[EMAIL PROTECTED]> wrote: >> 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 >> > > > > -- > 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 > D. Richard Hipp [EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
