On Thursday, 25 April, 2019 19:10, Lullaby Dayal <lullaby.tec...@gmail.com> wrote:
>We use sqlite3 in an embedded automotive system based on QNX >hypervisor running multiple virtual machines. Software is >architectured in a service oriented way. Interestingly, the default "database" service in QNX is (or at least was at one time) based on an implementation of SQLite. I do not know if this is still the case as it is a long time since I looked at and used QNX (It has been bought and sold several times since then). At the time the database service worked thusly: When you "connected" to the database service (by sending it a connect and open request) the underlying service created an SQLite connection object for you in the service context. All further requests that you submitted (by sending messages to your open context) occurred within this connection context. If you created another "connection" to the database service, then another SQLite connection context was created for that connection. It did not matter from whence the QNX database connection originated (ie, on the same machine or from another machine) as each connection was an independant SQLite connection from the QNX "database service process" to a local data file. Thus every "client" of the shared service was a separate connection context and isolated from every other client connection. Because of the way that the microkernel handled the message passing, all the connections were kept straight and the "going away" of a client (ie, a client program crash) was detected by the microkernel so the proper cleanup could occur automatically. In your service how do you identify the "client" and "connection on the client" in order to maintain isolation? And if you do it with session tokens or identifiers of some type passed back the the "client connection" how do you detect that a client has "gone missing" so that you can close and clean up the actual database connection? Just curious ... --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
