4 ** The author disclaims copyright to this source code. In place of
5 ** a legal notice, here is a blessing:
7 ** May you do good and not evil.
8 ** May you find forgiveness for yourself and forgive others.
9 ** May you share freely, never taking more than you give.
11 ******************************************************************************
13 ** This file contains demonstration code. Nothing in this file gets compiled
14 ** or linked into the SQLite library unless you use a non-standard option:
18 ** The configure script will never generate a Makefile with the option
19 ** above. You will need to manually modify the Makefile if you want to
20 ** include any of the code from this file in your project. Or, at your
21 ** option, you may copy and paste the code from this file and
22 ** thereby avoiding a recompile of SQLite.
25 ** This source file demonstrates how to use SQLite to create an SQL database
26 ** server thread in a multiple-threaded program. One or more client threads
27 ** send messages to the server thread and the server thread processes those
28 ** messages in the order received and returns the results to the client.
30 ** One might ask: "Why bother? Why not just let each thread connect
31 ** to the database directly?" There are a several of reasons to
32 ** prefer the client/server approach.
34 ** (1) Some systems (ex: Redhat9) have broken threading implementations
35 ** that prevent SQLite database connections from being used in
36 ** a thread different from the one where they were created. With
37 ** the client/server approach, all database connections are created
38 ** and used within the server thread. Client calls to the database
39 ** can be made from multiple threads (though not at the same time!)
41 ** (2) Beginning with SQLite version 3.3.0, when two or more
42 ** connections to the same database occur within the same thread,
43 ** they can optionally share their database cache. This reduces
44 ** I/O and memory requirements. Cache shared is controlled using
45 ** the sqlite3_enable_shared_cache() API.
47 ** (3) Database connections on a shared cache use table-level locking
48 ** instead of file-level locking for improved concurrency.
50 ** (4) Database connections on a shared cache can by optionally
51 ** set to READ UNCOMMITTED isolation. (The default isolation for
52 ** SQLite is SERIALIZABLE.) When this occurs, readers will
53 ** never be blocked by a writer and writers will not be
54 ** blocked by readers. There can still only be a single writer
55 ** at a time, but multiple readers can simultaneously exist with
56 ** that writer. This is a huge increase in concurrency.
58 ** To summarize the rational for using a client/server approach: prior
59 ** to SQLite version 3.3.0 it probably was not worth the trouble. But
60 ** with SQLite version 3.3.0 and beyond you can get significant performance
61 ** and concurrency improvements and memory usage reductions by going
64 ** Note: The extra features of version 3.3.0 described by points (2)
65 ** through (4) above are only available if you compile without the
66 ** option -DSQLITE_OMIT_SHARED_CACHE.
68 ** Here is how the client/server approach works: The database server
69 ** thread is started on this procedure:
71 ** void *sqlite3_server(void *NotUsed);
73 ** The sqlite_server procedure runs as long as the g.serverHalt variable
74 ** is false. A mutex is used to make sure no more than one server runs
75 ** at a time. The server waits for messages to arrive on a message
76 ** queue and processes the messages in order.
78 ** Two convenience routines are provided for starting and stopping the
81 ** void sqlite3_server_start(void);
82 ** void sqlite3_server_stop(void);
84 ** Both of the convenience routines return immediately. Neither will
85 ** ever give an error. If a server is already started or already halted,
86 ** then the routines are effectively no-ops.
88 ** Clients use the following interfaces:
90 ** sqlite3_client_open
91 ** sqlite3_client_prepare
92 ** sqlite3_client_step
93 ** sqlite3_client_reset
94 ** sqlite3_client_finalize
95 ** sqlite3_client_close
97 ** These interfaces work exactly like the standard core SQLite interfaces
98 ** having the same names without the "_client_" infix. Many other SQLite
99 ** interfaces can be used directly without having to send messages to the
100 ** server as long as SQLITE_ENABLE_MEMORY_MANAGEMENT is not defined.
101 ** The following interfaces fall into this second category:
105 ** sqlite3_clear_bindings
108 ** sqlite3_create_collation
109 ** sqlite3_create_function
110 ** sqlite3_data_count
114 ** sqlite3_last_insert_rowid
115 ** sqlite3_total_changes
116 ** sqlite3_transfer_bindings
118 ** A single SQLite connection (an sqlite3* object) or an SQLite statement
119 ** (an sqlite3_stmt* object) should only be passed to a single interface
120 ** function at a time. The connections and statements can be passed from
121 ** any thread to any of the functions listed in the second group above as
122 ** long as the same connection is not in use by two threads at once and
123 ** as long as SQLITE_ENABLE_MEMORY_MANAGEMENT is not defined. Additional
124 ** information about the SQLITE_ENABLE_MEMORY_MANAGEMENT constraint is
127 ** The busy handler for all database connections should remain turned
128 ** off. That means that any lock contention will cause the associated
129 ** sqlite3_client_step() call to return immediately with an SQLITE_BUSY
130 ** error code. If a busy handler is enabled and lock contention occurs,
131 ** then the entire server thread will block. This will cause not only
132 ** the requesting client to block but every other database client as
133 ** well. It is possible to enhance the code below so that lock
134 ** contention will cause the message to be placed back on the top of
135 ** the queue to be tried again later. But such enhanced processing is
136 ** not included here, in order to keep the example simple.
138 ** This example code assumes the use of pthreads. Pthreads
139 ** implementations are available for windows. (See, for example
140 ** http://sourceware.org/pthreads-win32/announcement.html.) Or, you
141 ** can translate the locking and thread synchronization code to use
142 ** windows primitives easily enough. The details are left as an
143 ** exercise to the reader.
145 **** Restrictions Associated With SQLITE_ENABLE_MEMORY_MANAGEMENT ****
147 ** If you compile with SQLITE_ENABLE_MEMORY_MANAGEMENT defined, then
148 ** SQLite includes code that tracks how much memory is being used by
149 ** each thread. These memory counts can become confused if memory
150 ** is allocated by one thread and then freed by another. For that
151 ** reason, when SQLITE_ENABLE_MEMORY_MANAGEMENT is used, all operations
152 ** that might allocate or free memory should be performanced in the same
153 ** thread that originally created the database connection. In that case,
154 ** many of the operations that are listed above as safe to be performed
155 ** in separate threads would need to be sent over to the server to be
156 ** done there. If SQLITE_ENABLE_MEMORY_MANAGEMENT is defined, then
157 ** the following functions can be used safely from different threads
158 ** without messing up the allocation counts:
160 ** sqlite3_bind_parameter_name
161 ** sqlite3_bind_parameter_index
163 ** sqlite3_column_blob
164 ** sqlite3_column_count
166 ** sqlite3_data_count
170 ** sqlite3_last_insert_rowid
171 ** sqlite3_total_changes
173 ** The remaining functions are not thread-safe when memory management
174 ** is enabled. So one would have to define some new interface routines
175 ** along the following lines:
177 ** sqlite3_client_bind_*
178 ** sqlite3_client_clear_bindings
179 ** sqlite3_client_column_*
180 ** sqlite3_client_create_collation
181 ** sqlite3_client_create_function
182 ** sqlite3_client_transfer_bindings
184 ** The example code in this file is intended for use with memory
185 ** management turned off. So the implementation of these additional
186 ** client interfaces is left as an exercise to the reader.
188 ** It may seem surprising to the reader that the list of safe functions
189 ** above does not include things like sqlite3_bind_int() or
190 ** sqlite3_column_int(). But those routines might, in fact, allocate
191 ** or deallocate memory. In the case of sqlite3_bind_int(), if the
192 ** parameter was previously bound to a string that string might need
193 ** to be deallocated before the new integer value is inserted. In
194 ** the case of sqlite3_column_int(), the value of the column might be
195 ** a UTF-16 string which will need to be converted to UTF-8 then into
199 /* Include this to get the definition of SQLITE_THREADSAFE, in the
200 ** case that default values are used.
202 #include "sqliteInt.h"
205 ** Only compile the code in this file on UNIX with a SQLITE_THREADSAFE build
206 ** and only if the SQLITE_SERVER macro is defined.
208 #if defined(SQLITE_SERVER) && !defined(SQLITE_OMIT_SHARED_CACHE)
209 #if SQLITE_OS_UNIX && SQLITE_THREADSAFE
212 ** We require only pthreads and the public interface of SQLite.
218 ** Messages are passed from client to server and back again as
219 ** instances of the following structure.
221 typedef struct SqlMessage SqlMessage
;
223 int op
; /* Opcode for the message */
224 sqlite3
*pDb
; /* The SQLite connection */
225 sqlite3_stmt
*pStmt
; /* A specific statement */
226 int errCode
; /* Error code returned */
227 const char *zIn
; /* Input filename or SQL statement */
228 int nByte
; /* Size of the zIn parameter for prepare() */
229 const char *zOut
; /* Tail of the SQL statement */
230 SqlMessage
*pNext
; /* Next message in the queue */
231 SqlMessage
*pPrev
; /* Previous message in the queue */
232 pthread_mutex_t clientMutex
; /* Hold this mutex to access the message */
233 pthread_cond_t clientWakeup
; /* Signal to wake up the client */
237 ** Legal values for SqlMessage.op
239 #define MSG_Open 1 /* sqlite3_open(zIn, &pDb) */
240 #define MSG_Prepare 2 /* sqlite3_prepare(pDb, zIn, nByte, &pStmt, &zOut) */
241 #define MSG_Step 3 /* sqlite3_step(pStmt) */
242 #define MSG_Reset 4 /* sqlite3_reset(pStmt) */
243 #define MSG_Finalize 5 /* sqlite3_finalize(pStmt) */
244 #define MSG_Close 6 /* sqlite3_close(pDb) */
245 #define MSG_Done 7 /* Server has finished with this message */
249 ** State information about the server is stored in a static variable
250 ** named "g" as follows:
252 static struct ServerState
{
253 pthread_mutex_t queueMutex
; /* Hold this mutex to access the msg queue */
254 pthread_mutex_t serverMutex
; /* Held by the server while it is running */
255 pthread_cond_t serverWakeup
; /* Signal this condvar to wake up the server */
256 volatile int serverHalt
; /* Server halts itself when true */
257 SqlMessage
*pQueueHead
; /* Head of the message queue */
258 SqlMessage
*pQueueTail
; /* Tail of the message queue */
260 PTHREAD_MUTEX_INITIALIZER
,
261 PTHREAD_MUTEX_INITIALIZER
,
262 PTHREAD_COND_INITIALIZER
,
266 ** Send a message to the server. Block until we get a reply.
268 ** The mutex and condition variable in the message are uninitialized
269 ** when this routine is called. This routine takes care of
270 ** initializing them and destroying them when it has finished.
272 static void sendToServer(SqlMessage
*pMsg
){
273 /* Initialize the mutex and condition variable on the message
275 pthread_mutex_init(&pMsg
->clientMutex
, 0);
276 pthread_cond_init(&pMsg
->clientWakeup
, 0);
278 /* Add the message to the head of the server's message queue.
280 pthread_mutex_lock(&g
.queueMutex
);
281 pMsg
->pNext
= g
.pQueueHead
;
282 if( g
.pQueueHead
==0 ){
285 g
.pQueueHead
->pPrev
= pMsg
;
289 pthread_mutex_unlock(&g
.queueMutex
);
291 /* Signal the server that the new message has be queued, then
292 ** block waiting for the server to process the message.
294 pthread_mutex_lock(&pMsg
->clientMutex
);
295 pthread_cond_signal(&g
.serverWakeup
);
296 while( pMsg
->op
!=MSG_Done
){
297 pthread_cond_wait(&pMsg
->clientWakeup
, &pMsg
->clientMutex
);
299 pthread_mutex_unlock(&pMsg
->clientMutex
);
301 /* Destroy the mutex and condition variable of the message.
303 pthread_mutex_destroy(&pMsg
->clientMutex
);
304 pthread_cond_destroy(&pMsg
->clientWakeup
);
308 ** The following 6 routines are client-side implementations of the
309 ** core SQLite interfaces:
318 ** Clients should use the following client-side routines instead of
319 ** the core routines above.
321 ** sqlite3_client_open
322 ** sqlite3_client_prepare
323 ** sqlite3_client_step
324 ** sqlite3_client_reset
325 ** sqlite3_client_finalize
326 ** sqlite3_client_close
328 ** Each of these routines creates a message for the desired operation,
329 ** sends that message to the server, waits for the server to process
330 ** then message and return a response.
332 int sqlite3_client_open(const char *zDatabaseName
, sqlite3
**ppDb
){
335 msg
.zIn
= zDatabaseName
;
340 int sqlite3_client_prepare(
344 sqlite3_stmt
**ppStmt
,
348 msg
.op
= MSG_Prepare
;
354 if( pzTail
) *pzTail
= msg
.zOut
;
357 int sqlite3_client_step(sqlite3_stmt
*pStmt
){
364 int sqlite3_client_reset(sqlite3_stmt
*pStmt
){
371 int sqlite3_client_finalize(sqlite3_stmt
*pStmt
){
373 msg
.op
= MSG_Finalize
;
378 int sqlite3_client_close(sqlite3
*pDb
){
387 ** This routine implements the server. To start the server, first
388 ** make sure g.serverHalt is false, then create a new detached thread
389 ** on this procedure. See the sqlite3_server_start() routine below
390 ** for an example. This procedure loops until g.serverHalt becomes
393 void *sqlite3_server(void *NotUsed
){
394 if( pthread_mutex_trylock(&g
.serverMutex
) ){
395 return 0; /* Another server is already running */
397 sqlite3_enable_shared_cache(1);
398 while( !g
.serverHalt
){
401 /* Remove the last message from the message queue.
403 pthread_mutex_lock(&g
.queueMutex
);
404 while( g
.pQueueTail
==0 && g
.serverHalt
==0 ){
405 pthread_cond_wait(&g
.serverWakeup
, &g
.queueMutex
);
410 pMsg
->pPrev
->pNext
= 0;
414 g
.pQueueTail
= pMsg
->pPrev
;
416 pthread_mutex_unlock(&g
.queueMutex
);
419 /* Process the message just removed
421 pthread_mutex_lock(&pMsg
->clientMutex
);
424 pMsg
->errCode
= sqlite3_open(pMsg
->zIn
, &pMsg
->pDb
);
428 pMsg
->errCode
= sqlite3_prepare(pMsg
->pDb
, pMsg
->zIn
, pMsg
->nByte
,
429 &pMsg
->pStmt
, &pMsg
->zOut
);
433 pMsg
->errCode
= sqlite3_step(pMsg
->pStmt
);
437 pMsg
->errCode
= sqlite3_reset(pMsg
->pStmt
);
441 pMsg
->errCode
= sqlite3_finalize(pMsg
->pStmt
);
445 pMsg
->errCode
= sqlite3_close(pMsg
->pDb
);
450 /* Signal the client that the message has been processed.
453 pthread_mutex_unlock(&pMsg
->clientMutex
);
454 pthread_cond_signal(&pMsg
->clientWakeup
);
456 pthread_mutex_unlock(&g
.serverMutex
);
461 ** Start a server thread if one is not already running. If there
462 ** is aleady a server thread running, the new thread will quickly
463 ** die and this routine is effectively a no-op.
465 void sqlite3_server_start(void){
469 rc
= pthread_create(&x
, 0, sqlite3_server
, 0);
476 ** A wrapper around sqlite3_server() that decrements the int variable
477 ** pointed to by the first argument after the sqlite3_server() call
480 static void *serverWrapper(void *pnDecr
){
481 void *p
= sqlite3_server(0);
487 ** This function is the similar to sqlite3_server_start(), except that
488 ** the integer pointed to by the first argument is decremented when
489 ** the server thread exits.
491 void sqlite3_server_start2(int *pnDecr
){
495 rc
= pthread_create(&x
, 0, serverWrapper
, (void*)pnDecr
);
502 ** If a server thread is running, then stop it. If no server is
503 ** running, this routine is effectively a no-op.
505 ** This routine waits until the server has actually stopped before
508 void sqlite3_server_stop(void){
510 pthread_cond_broadcast(&g
.serverWakeup
);
511 pthread_mutex_lock(&g
.serverMutex
);
512 pthread_mutex_unlock(&g
.serverMutex
);
515 #endif /* SQLITE_OS_UNIX && SQLITE_THREADSAFE */
516 #endif /* defined(SQLITE_SERVER) */