This article describe how concurrent db-api requests are handled by the server and what limitations exist.


The server serializes all the request coming from the db-api-app and handles them one after another.


Examples:


Concurrent GET and EDIT requests scenario


1) In this scenario there are two subsystems. The first subsystem (Subsys1) sends GET request and Subsys2 sends EDIT request at the same time. Assume Subsys1 GET request got to the server first and it takes 10 seconds to process this GET request:


Subsys1 GET request takes 10 second -> The Subsys2 EDIT request waits when Subsys1 GET is done.

2) In this scenario there are the same two subsystems. The first subsystem (Subsys1) sends the same GET request and Subsys2 sends another EDIT request at the same time. Assume Subsys2 EDIT request got to the server first and it takes 10 seconds to process this EDIT request:


Subsys2 EDIT request takes 10 second -> Subsys1 GET request waits when Subsys2 EDIT is done.

Concurrent multiple EDIT requests scenario


3) In this scenario there are two subsystems that both sends EDIT requests at the same time. The requests are getting serialized and the server handles the edits one after another.


Subsys1 EDIT request takes 10 seconds -> the Subsys2 EDIT request waits when the Subsys1 EDIT is done.

Concurrent multiple GET requests scenario


4) In this scenario there are two subsystems that both sends GET requests at the same time. The requests are getting serialized and the server handles the GET request one after another.

Subsys1 GET request takes 10 seconds -> Subsys2 GET request waits when the Subsys1 GET is done.