Platform: windows
I want to explore replacing b-tree database (ISAM/Index files) in our
backend RPC server with SQLITE3. I'm relatively new to SQLITE3 and
just reading up on its multi-thread and pooling framework. I'm not
quite sure how to implement it, but it seems I should be able once
understood.
Some insights would be appreciated. Here is some backend.
We need to maintain API backward compatibility on the client side, for
example, the API had traversal functions such as:
BOOL wcGetFirstFileRec(TFileRecord &fr, DWORD &tid);
BOOL wcGetNextFileRec(TFileRecord &fr, DWORD &tid);
BOOL wcGetPrevFileRec(TFileRecord &fr, DWORD &tid);
BOOL wcGetLastFileRec(TFileRecord &fr, DWORD &tid);
The tid is a handle returned to the last position in the server's
btree page chain. So as long as its persistent, a loop such as this
can be done:
TFileRecord fr = {0}
DWORD tid = 0;
if (wcGetFirstFileRec(ft,tid)) do {
....
} while (wcGetNextFileRec(ft,tid));
On the backend, if tid is not zero, then it jumps to the position in
the index page to get the next/prev record position and thus ISAM record.
While the plan is provide new API functions specific for bulk
operations over the wire, we need to keep compatible with the
existing API.
So my question is, given there are two SQLITE3 objects:
SQLITE3 *db <-- pointer to the database
SQLITE3_STM *stm <-- pointer to query
what strategy do I look at to provide RPC thread context integrity on
the backend. Each API function has a context handle so each thread
will have its own instance of context block to work with.
Right now the btree database is globally opened exclusively by the
server and reader/writer locking is used for the server-side API I/O.
This is why it appears I should be able to replace the database with
SQLITE3 and at the very least keep the concurrency integrity.
So my initial thought was to open the database globally as its done
now and then for each thread context, maintain a context handle mapped
list of SQLITE3_STM pointers as they are opened. They will be created
when GetFirstFileRec() or GetLastFileRec() are called returning tid as
the index/handle to SQLITE3_STM pointer. It will be passed back in
Next/Prev as the SQLITE3_STM pointer along to continue with a fetch call.
Anyway, I am not sure if this is the wrong approach with SQLITE3, or
will be duplicating work, or there is a workable strategy already for
SQLITE3 for multithread client/server frameworks.
Thanks in Advance
PS: Researching this shows strategy where connection pools are used.
But I didn't see the integrity of this without having a cursor pool.
Does the SQLITE3 library maintain a list of cursors per connection?
--
HLS
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
