← Back to branch summary

~ubuntu-branches/ubuntu/hardy/sqlite3/hardy

« back to all changes in this revision

Viewing changes to www/faq.tcl

  • Committer: Bazaar Package Importer
  • Author(s): Matthias Klose
  • Date: 2007-07-23 14:35:04 UTC
  • mfrom: (1.1.10 upstream)
  • Revision ID: james.westby@ubuntu.com-20070723143504-v52h2illx871jas3
Tags: 3.4.1-0ubuntu1
https://launchpad.net/bugs/127223
New upstream release. Closes LP: #127223.

Show diffs side-by-side

added added

removed removed

Lines of Context:
www/faq.tcl
1
1
#
2
2
# Run this script to generated a faq.html output file
3
3
#
4
 
set rcsid {$Id: faq.tcl,v 1.37 2007/06/09 09:53:51 drh Exp $}
 
4
set rcsid {$Id: faq.tcl,v 1.38 2007/06/27 00:08:40 drh Exp $}
5
5
source common.tcl
6
6
header {SQLite Frequently Asked Questions</title>}
7
7
 
154
154
  <p>When SQLite tries to access a file that is locked by another
155
155
  process, the default behavior is to return SQLITE_BUSY.  You can
156
156
  adjust this behavior from C code using the 
157
 
  <a href="capi3ref#sqlite3_busy_handler">sqlite3_busy_handler()</a> or
158
 
  <a href="capi3ref#sqlite3_busy_timeout">sqlite3_busy_timeout()</a>
 
157
  <a href="capi3ref.html#sqlite3_busy_handler">sqlite3_busy_handler()</a> or
 
158
  <a href="capi3ref.html#sqlite3_busy_timeout">sqlite3_busy_timeout()</a>
159
159
  API functions.</p>
160
160
}
161
161
 
171
171
  <p>"Threadsafe" in the previous paragraph means that two or more threads
172
172
  can run SQLite at the same time on different "<b>sqlite3</b>" structures
173
173
  returned from separate calls to 
174
 
  <a href="capi3ref#sqlite3_open">sqlite3_open()</a>.  It is never safe
 
174
  <a href="capi3ref.html#sqlite3_open">sqlite3_open()</a>.  It is never safe
175
175
  to use the same <b>sqlite3</b> structure pointer in two
176
176
  or more threads.</p>
177
177
 
178
178
  <p>Prior to version 3.3.1,
179
179
  an <b>sqlite3</b> structure could only be used in the same thread
180
 
  that called <a href="capi3ref#sqlite3_open">sqlite3_open</a> to create it.
 
180
  that called <a href="capi3ref.html#sqlite3_open">sqlite3_open</a>
 
181
  to create it.
181
182
  You could not open a
182
183
  database in one thread then pass the handle off to another thread for
183
184
  it to use.  This was due to limitations (bugs?) in many common threading
194
195
  can safely assume that no locks are being held if no
195
196
  transaction is pending and all statements have been finalized.</p>
196
197
 
 
198
  <p>If you turn on
 
199
  <a href="capi3ref.html#sqlite3_enable_shared_cache">shared cache</a>
 
200
  mode or if you compile with the -DSQLITE_ENABLE_MEMORY_MANAGEMENT=1
 
201
  option, then you can never move an <b>sqlite3</b> pointer across
 
202
  threads.  The <b>sqlite3</b> pointer must only be used in the same
 
203
  thread in which it was created by 
 
204
  <a href="capi3ref.html#sqlite3_open">sqlite3_open()</a>.  If you
 
205
  break the rules and use an <b>sqlite3</b> in more than one thread
 
206
  under these circumstances, then you will likely corrupt some
 
207
  internal data structures resulting in a crash.</p>
 
208
 
197
209
  <p>Under UNIX, you should not carry an open SQLite database across
198
210
  a fork() system call into the child process.  Problems will result
199
211
  if you do.</p>