Folks,
I read the documentation suggesting to use another SQL engine for a
multi-threaded client/server environment and I reached a point where I
see why. But I was thinking it could be used because currently, we
have a ISAM/BTREE database under our full reader/writer and exclusive
locking controls. So my attempt was to basically plug and play
SQLITE3.
What I need is NO LOCKING so we can use our own thread context
contention controls.
I read the technical notes but I'm still getting either a error 5 or
8. I'm not entirely sure what steps need to be done. I tried:
sqlite3_config(SQLITE_CONFIG_MULTITHREAD);
Overall, the design is the RPC server opens exclusive the database
file, and each thread context gets a query cursor. Since the client
API has no concept of a "close", the cursor is saved in the server
thread context and reused for NEXT/PREV client function, so on the
client side, a example code:
TFileRecord rec = {0};
DWORD tid = 0;
if (SearchFileRec(FileNameAreaKey, rec, tid) do {
... do something with rec ...
} while (GetNextFilerec(FileNameAreaKey, rec, tid));
Here, in the current system, the tid holds a pointer to the btree page
allowing for the traversal. But for the SQLITE3 implementation, the
search cursor is saved in the context and recalled in the Next call.
So as you can imagine what happen now if there any record updating:
if (SearchFileRec(FileNameAreaKey, rec, tid) do {
rec.XXXX = change some fields
UpdateFileRec(rec);
} while (GetNextFilerec(FileNameAreaKey, rec, tid));
I am now getting a sharing issue with the UpdateFileRec().
I think before we punt on SQLITE3, we can use it if we had full
control of the I/O access to the database. No other process will be
allowed access to the database because I am going to open it in none
sharing more. All access will be through the client API.
So how do I make it so there is no locking?
--
hls
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
