Hacker News Reader

Comment by ericsink | Hacker News Reader

No offense intended, but that's not correct. :-(

You can get this problem with two instances of the same version of SQLite (accessing the same file at the same time).

I was only considering the conflict between the system-provided SQLite and the private copy of SQLite in your binary, since that seemed to be what your article was about, and is the most common conflict. I hadn't actually considered that you would actually statically link two copies of the same version (or even different versions) of SQLite into your own binary and use those two different copies of SQLite to open connections to the same exact file.

In any case, don't have two different versions (by versions I mean copies) of SQLite open the same file in the same process. This is because os_unix.c does deferred closing of fds based on refcounting the number of open connections to the same path. With multiple libraries opening connections to the same path, the refcount for that path won't be correct in either copy of the library.

.... that's very different from what's stated in the article, and is actually what I'd expect to be the real problem. Dwelling on versions seems to be beside the point.

Sorry if the article is unclear. My intent was to clearly communicate that the problem can happen with any two instances, not necessarily of different versions. Like the nutshell summary at the top says.

But I also think that talking about different versions of SQLite is relevant, since dealing with those issues is one of the things that can lead an app developer toward the problem.

From the same process? Is there better documentation for this issue somewhere?

Reply on news.ycombinator.com