Ran <[EMAIL PROTECTED]> wrote: > Hi all, > > I *think* that sqlite3_close behave strangly. > > I use version 3.3.7 on Linux (Fedora Core 5). > > What I do is to open a database, and start a transaction in it. Then, > without ending the transaction, open again the database and simply close it. > > I found out, that the inner sqlite3_close return 0 (SQLITE_OK), but the > file handle is not released. So if I do it too many times, I run out of file > handles. >
This behavior is intentional. It is a work-around for a bug in the design of posix advisory locks. With posix advisory locks, if you open the same file twice, giving two file descriptors, then you close one of the file descriptors, it deletes all the locks on the other file descriptor. (No, I am not making this up - I wish I were. This is proscribed behavior in the posix standard.) So if you have a database open and in a transaction, it that database connection is holding a lock. If you opened a second connection and immediately closed it, and if that close operation actually closed the file handle, then the locks held by the first connection would be released. This would free other processes to start reading and writing the database while an update was still going on - resulting in database corruption. In order to prevent database corruption, SQLite embargos all file close operations until all locks on that same file (possibly held by different threads) have cleared. See http://www.sqlite.org/cvstrac/tktview?tn=561 and http://www.sqlite.org/cvstrac/chngview?cn=1171 for additional information. -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
