在不同的平台上使用sqlite和文件锁定有已知的问题吗？ [英] Are there known issues with using sqlite and file locking on different platforms?

问题描述

我使用sqlite做一个专有文件的索引，数据库将被多个线程（使用不同的sqlite句柄）读取和写入。

<我知道，sqlite锁定文件，以提供读者/作家的并发性，并取决于操作系统文件api的锁定。

这一切都很好，在Windows和linux，但是在solaris和hpux上，我对于如何使用咨询锁定没有多大信心。

有没有人知道sqlite在这些平台上的并发性如何？在我的经验（虽然基于有点过时的SQLite版本，即3.0.x - 3.2.x），你不想要的当存在某种争用时，即使它只是多个线程，也要依靠SQLite的默认锁定实现。

主要的问题是SQLite只是睡觉一会儿，然后再试一次，如果文件哈被锁定（直到繁忙的等待超时到期） - 这可能导致应用程序中的数据库锁定错误。我已经实现的解决方法是使用自己的锁定（在多线程进程中使用互斥锁），除了SQLite自己的锁定。

I'm using sqlite to do an index of a proprietary file, and the database will be accessed with multiple threads (using different sqlite handles) for reading and writing.

I know that sqlite locks the file in order to provide concurrency for readers/writers, and depends on the OS file api for locking.

This is all fine on windows and linux, but on solaris and hpux I am less confident regarding how advisory locking works there.

Does anyone have any idea how well sqlite works regarding concurrency on those platforms?

解决方案

In my experience (although based on somewhat dated SQLite versions, i.e. 3.0.x - 3.2.x) you don't want do rely on SQLite's default locking implementation when there is some kind of contention (even if it's just multiple threads in the same process).

The main problem is that SQLite just sleeps for a little while and then tries again if the file has been locked (until the busy wait timeout expires) - this is likely to result in "database locked" errors in the application. The workaround I have implemented was to use my own locking (using a mutex in a multi-threaded process) in addition to SQLite's own locking.

这篇关于在不同的平台上使用sqlite和文件锁定有已知的问题吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！