Pooling, Thread ?

[Abaksoft]

@Farshad,

Hello Farshad,

i would like to show you this code from Oleg / Devart :

 

https://forums.devart.com/viewtopic.php?f=28&t=39169&hilit=LConnection.PoolingOptions&start=15#p171444

Till now, we are puting on MainModule, the DB Connection component (without pooling technic). Ok, all works fine : each new session uses its own connecting resources.

Today, we want to exploit the benefits of pooling.  Many puzzles persist in my mind :

•  If we activate pooling connection, is that enough to work fine on unigui ?

•  Or do we have to take care of threads considerations  (as Unigui is multi threads environment). ?

Thx.

[Mehmet Emin]

Hi Abaksoft

Before you get the authorised answer of Farshad I would like share my opinion.

The method to place the database session component on ServerModule and the database connection component on the MainModule is the way to go because uniGUI handles user requests in a multi-threaded way and 99% of SQL components in the market requires their connection component to be used by one thread at a time.

This architecture of uniGUI is fine as long as we get the resources when we need them and release them when the job done.

For example FireDAC has connection pooling and offlining option. If you use FireDAC's offlining option you don't have to leave your connection open (you dont have to allocate it to one user during uniGUI session). As you finish getting your data to your datasets during handling client ajax calls just call the TFDCustomConnection.Offline method. This way you will close the connection resource and give it back to connection pool. Your datasets will be operational even after offlining. When you want to save changes etc. (when user saves) you can call Online method or there is implicit automatic activation.

So this offlining option is critically important to share connections between uniGUI sessions.

[Abaksoft]

1 hour ago, Mehmet Emin said:

Hi Abaksoft

Before you get the authorised answer of Farshad I would like share my opinion.

The method to place the database session component on ServerModule and the database connection component on the MainModule is the way to go because uniGUI handles user requests in a multi-threaded way and 99% of SQL components in the market requires their connection component to be used by one thread at a time.

This architecture of uniGUI is fine as long as we get the resources when we need them and release them when the job done.

For example FireDAC has connection pooling and offlining option. If you use FireDAC's offlining option you don't have to leave your connection open (you dont have to allocate it to one user during uniGUI session). As you finish getting your data to your datasets during handling client ajax calls just call the TFDCustomConnection.Offline method. This way you will close the connection resource and give it back to connection pool. Your datasets will be operational even after offlining. When you want to save changes etc. (when user saves) you can call Online method or there is implicit automatic activation.

So this offlining option is critically important to share connections between uniGUI sessions.

Thank you Mehmet.