*** 7,15 ****
multithreading that isn't covered here, feel free to add it. Some of the references in this paper are Mac
OS X related because this is the environment I've been working on.
! **Is SQLite thread-safe?**
! Yes, it is, but be {link: http://www.hwaci.com/sw/sqlite/faq.html#q8 careful}.
**SQLite multithreading settings**
--- 7,96 ----
multithreading that isn't covered here, feel free to add it. Some of the references in this paper are Mac
OS X related because this is the environment I've been working on.
! ***Is SQLite thread-safe?***
! *Short answer:* Yes
!
! *Medium length answer:*
!
! 1: Be sure to recompile with -DTHREADSAFE=1
! 2: Do not use the same database connection at the same time in more than
! one thread.
! 3: On some operating systems, a database connection should always be used
! in the same thread in which it was originally created.
! 4: There are a few features of SQLite that are not threadsafe. Avoid those
! features.
!
! *Longer answer:*
!
! The precompiled binaries for windows have traditionally been threadsafe.
! The precompiled binaries for unix have not been. That might change in the
! future, so always check. But in the past, if you wanted a thread-safe
! version of SQLite for unix, you'd need to get the sources and compile
! it yourself.
!
! By "threadsafe" we mean that you can use different SQLite database connections
! in different threads at the same time. It has never been safe to use the
! same database connection simultaneously in multiple threads. If you
! use the {link: http://www.sqlite.org/capi3ref.html#sqlite3_prepare sqlite3_prepare()} API to create prepared statements, each prepared statement
! is considered to be a part of the database connection from which it was
! derived. So you cannot
! run two prepared statements originating from the same database connection
! in different threads at the same time.
!
! There is a bug in some Linux implementations (RedHat9 is the canonical
! example) that prevents fcntl() locks created by one thread from being
! modified in a different thread. If you are running on one of those
! systems, then you should always use an SQLite database connection in
! the same thread in which it was originally created. It is not safe to
! open the database in one thread and then pass the connection off to a
! different thread for processing.
!
! The restriction of the previous paragraph has been relaxed somewhat as
! of SQLite version 3.3.1. Beginning with version 3.3.1, you should be
! able to move database connections from one thread to another as long as
! there are no locks outstanding at the time you move the thread. If you
! are not running on one of the systems effected by the fcntl() locking bug,
! then you can move your database connections at any time you want. But
! for portability, you probably should assume your system has the bug.
!
! So, beginning with version 3.3.1, the common paradigm of maintaining a
! pool of database connections and handing them off to worker threads for
! processing should work fine - as long as your worker threads are
! careful to
! {link: http://www.sqlite.org/capi3ref.html#sqlite3_finalize finalize}
! all of their prepared statements prior to exiting.
! For added safety, your worker threads would do well to call
! {link: http://www.sqlite.org/capi3ref.html#sqlite3_thread_cleanup sqlite3_thread_cleanup()} before exiting - though this is only a
! precaution against latent bugs and is not strictly necessary.
!
! If you compile SQLite with the -DSQLITE_ENABLE_MEMORY_MANAGEMENT=1 option,
! then SQLite maintains a count of all outstanding memory allocations for
! each thread. In that case, you should only use an SQLite database connection
! in the same thread in which it was originally created - otherwise things
! will be malloc()-ed in one thread and free()-ed in another and the counts
! will get all out-of-whack. The -DSQLITE_ENABLE_MEMORY_MANAGEMENT feature
! is generally only useful for low-memory embedded devices. If you do not
! need it you are well advised to leave it turned off. It is turned off by
! default.
!
! If you enable the shared cache feature of SQLite using the
! {link: http://www.sqlite.org/capi3ref.html#sqlite3_enable_shared_cache sqlite3_enable_shared_cache()} API, then database connections that use
! the shared cache should only be used in the same thread in which they
! were originally created.
!
! The {link: http://www.sqlite.org/pragma.html#pragma_temp_store_directory PRAGMA temp_store_directory} SQL statement is not thread-safe. If you need to
! change the directory in which SQLite is storing temporary files, do so once
! at program initialization and thereafter leave the setting along.
!
! The "localtime" modifier for the built-in date/time functions uses the
! localtime() C API, which is not threadsafe. The call to localtime()
! in SQLite is
! protected by a mutex, so the "localtime" modifier is safe to use as long
! as nothing else in your program calls localtime() independently of SQLite.
!
! Any aspect of SQLite that is not mentioned above is considered threadsafe.
! If you have doubts, as on the mailing list.
**SQLite multithreading settings**
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|