Hello @y.ivanov,
The MVCC model of the Firebird can be source of some confusion when dealing with multiple connections.
I would like to use the already same and shared and thread-safe connection, between all threads-queries, of course
.
Hence this question: the IBX IBXDatabase (connection) is already shareable, or have I to recreate it for each thread if it make sense, or I have to make it (program singleton) thread-safe with a shared access by each thread-query between all the existing threads-queries.
Would you please share some more details for the application? Why multiple threads were needed? Will they only write or will also modify data from another threads?
For example, I would like to be able to do "data-pumping" by a computer-automated thread-query, which should therefore work in parallel with the other threads-queries triggered by the events in the main-UI-thread.
IMHO, it is always better to keep minimal number of connections and use them to isolate GUI from the worker threads (i.e. two) or to organize some kind of connections pool. After all, their features (isolation, serialization) come with a price.
So, your advice would be to create a "pool" of working thread sessions (=~ the "old" TSessionList), with 2 IBXDatabases a.k.a. 2 connections - one dedicated for the main-GUI-thread, and one dedicated for the background thread-queries; each IBXDatabase-connection permitting one TTransaction [startTransaction..commitTransaction] a.k.a. InTransaction, at a time (=~ 2 "old" TSession). So, to resume:
- one dedicated to the interface (it is true that the user cannot duplicate himself in parallel
).
- another one, isolated from the main-GUI-thread, serialization among the threads-queries in the background. Hence this question: this last one IBX IBXDatabase (connection) is already sharable between background multiple threads-queries.
To resume, the software layer of the background threads-queries could be like that:
<Lazarus soft.'s IBX layer...
┌---------------┐┌---------------┐
| transaction 1|| transaction 2 |
└---------------┘└---------------┘
↖↘ ↗↙
┌---------------┐┌---------------┐
| connection 1 |
| a singleton,in this case |
| (thread safe and sharable) |
└---------------┘└---------------┘
...Lazarus soft.'s IBX layer>
↑↓
<FireBird client library layer...
┌---------------┐┌---------------┐
| libfbclient |
| (black box, for me) |
└---------------┘└---------------┘
...FireBird client library layer>
↑↓
<FireBird server embedded, or not...
┌---------------┐┌---------------┐
| firbird 3.x server |
| (black box, for me) |
└---------------┘└---------------┘
↗↙ ↖↘
┌---------------┐┌---------------┐
| transaction 1 || transaction 2 |
| reification || reification |
└---------------┘└---------------┘
...FireBird server embedded, or not>
So, displayed differently, IBX background thread_1-query should\could create\manage these (?)...:
┌---------------┐
| transaction 1 |
└---------------┘
↖↘
┌---------------┐┌---------------┐
| connection 1 |
| a singleton,in this case |
| (thread safe and sharable) |
└---------------┘└---------------┘
... and IBX background thread_2-query should\could create\manage these (?)...:
┌---------------┐
| transaction 2 |
└---------------┘
↗↙
┌---------------┐┌---------------┐
| connection 1 |
| a singleton,in this case |
| (thread safe and sharable) |
└---------------┘└---------------┘
Said differently, in the <Lazarus soft.'s IBX layer>, is there a software resource, which is a non-thread-safe shareable resource\object between multiple background threads-queries (a bottleneck, that must be protected in read and in write access by a critical section between all background threads-queries during their execute method)?
Does it make sense to think like this, with IBX components + firebird 3.x client library? Can it be improved?