> .... I expect process B able to > read the old data and displays appropriately. But, process B seems to be > blocked. Why is this so as I thought SQLite handle concurrency as in this > case where there are multiple reads and one single write ? >
After Pavel's explanation just reread http://www.sqlite.org/lockingv3.htmland can add that PENDING lock theoretically allow reading for an existing SHARED reader, but as I suppose single SELECT operation acquires SHARED and releases it right at the end of the query so if your "display" process is not in process of some sqlite operation, it probably has no SHARED lock so for any new Select it is considered "new" so prohibited. As long as I see the moment when the lock moves from RESERVED to PENDING depends on the write cache size. I just made a test with two admins accessing the same base and for a fresh base without any pragma tuning several megabytes of inserts passed without changing the lock. But the question is why do you need this kind of concurrency at all? If your insert is small and wrapped in a single transaction, your "display" application should not show noticeable "hanging" (if it just waits for SQLITE_BUSY to disappear). On the other side If you do some caching starting transaction and ending it only after some time, you may consider Commit on a time basis so to give your "display" process chance to read the base. Anyway I think holding single transaction for a long time is not a good idea so coniser optimizing your write operations Max _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users