It’s less complicated than a web service. There is no “server” per se, only a
lightweight listener object that can accept and respond to HTTP requests (C#
HttpListener class). The short explanation is that the library I develop
(Couchbase Lite) has a replication function that allows it to communicate with
an endpoint that implements the CouchDB sync protocol. As part of that, in
order to enable device to device replication, there is also a listener
component distributed as an optional part of Couchbase Lite which embeds a
listener for REST requests into the process. So yes, multiple threads are at
play here, but in the scenario there would be three at most: The thread that
requested the PUT, the thread that wrote to the database, and the thread the
requested the GET. All write requests to the database are moderated through
the write connection thread and will block the calling thread until the write
operation is complete. So, as you noted, this is why I am able to return the
correct status for any given operation (almost, aside from this odd 404 issue).
Also, this situation is relatively rare which makes it more annoying.
All of the code is in one process compiled together (the listener, the storage
API, the app, etc), and written all in C# with interop calls to C.
Thanks for your input. The clarification about COMMIT was enough for me to
focus my attention elsewhere and has been helpful.
Jim Borden
Software Engineer
jim.bor...@couchbase.com
On 2016/09/29 17:32, "sqlite-users on behalf of Simon Slavin"
<sqlite-users-boun...@mailinglists.sqlite.org on behalf of
slav...@bigfraud.org> wrote:
On 29 Sep 2016, at 8:59am, Jim Borden <jim.bor...@couchbase.com> wrote:
> There is a web API
If you're using a conventional server as the front end to your web service
(e.g. Apache, with your code written in PHP/Python/C/whatever) then the server
spawns a new process to handle each incoming request. So it's possible for two
calls to execute at the same time and you do have to worry about
multiprocessing.
However, there is a question of how SQLite connections are maintained.
Does the web service open some connections when it is started and maintain them
throughout its life, or does it create a new connection to answer each PUT or
GET ? The answer is important because a savepoint is handled by a specific
connection. Close the connection and your savepoint vanishes.
Also, depending on how your code is written the server may be sending back
the acknowledgement for the PUT first, and then doing the database operations
while your program is already moving on to do something else. But that would
make it impossible to return a different HTTP response code if the PUT fails.
It's more likely that the PUT operation waits until the database connection is
finished before returning its HTTP response code, to allow it to report errors.
In which case I don't see how your problem could occur. But someone else
might.
Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
