mORMot Open Source

AntonE

Member

Registered: 2012-02-03

Posts: 74

Server threads & Database

I have a HTTP server (like Sample 4) but need to have Threads running in background that does various tasks. Some of these tasks involve heavy DB access.
I am concerned that my Threads that run on server, will cause problems.

Should I do something to avoid/detect e.g. simultaneous access by a 'server worker thread' and a Client request to same Object?
What happens if 2 threads calls SQLRestServerDB.Update at the same time...
(Or Should each thread create a client connection to server?)

Regards
AntonE

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,238

Website

Re: Server threads & Database

Search for multi-thread in the SAD pdf, and you will find some points.

In short:
- SQLite3 access is protected by a shared section;
- RESTful routing, serializing, and read process (Retrieve) is mostly thread-safe, and has been tested to work in multi-thread, using as most CPU power as possible;
- RESTful write process (Update/Write/Delete) are locked within a critical section, so it will be safe for all ORM process, including both the internal SQLite3 engine or external DBs;
- Cache is also protected and handed to be thread safe.
- Services shall be implemented thread-safe by themself.

About SynDB connections, it depends on the provider.
Some providers use a shared connection instance, other create one connection per thread.
All this is made by itself, you do not have to handle it.

In a HTTP server, the threads are the one processing the incoming requests (i.e. from the HTTP server thread pool).
mORMot does not creates its own threads for processing the data: it processes the incoming requests, from the input threads.
You can add threads to the HTTP thread pool, if needed.

I want to add some internal thread pool within mORMot interface-based services.
We need enhanced threading for event process (which are asynchronous by nature) - so a new execution option for the interface factories of mORMot core is a good idea.
For heavy process (like huge DB access), you could either use the BATCH mode, or an event driven orientation: you launch the request, which is processed in its own thread, then ask later if it was processed.