Scenario 1 - you leave the "Pool Data Connections" unchecked in the Intraweb Application Wizard
In this case, the wizard creates a ServerController , a UserSession , but not a DataModule . You host the database, session, and dataset components on a UserSession .
When a new user connects to your website, a new instance of UserSession is created and a connection to the database is created. When ServerController.SessionTimeOut expires due to user inactivity, the UserSession destroyed and this particular database connection is disconnected.
For 30 concurrent users, this model is likely to be okay for you and should ensure that all database connections are disconnected when the website is not in use.
Scenario 2 - you check "Pool Data Connections" in the Intraweb Application Wizard
Like ServerController and UserSession , the wizard will create an empty DataModule . You host database, session, and dataset components on a DataModule .
ServerModule has a TIWDataModulePool component on it that has the PoolCount property.
When the application starts, PoolCount creates PoolCount instances, each of which makes a connection to the database. Because your pages require access to the database, they call LockDataModule and UnlockDataModule to temporarily use one of the DataModule instances from the pool.
When the application closes, the DataModule instances in the pool are destroyed and their database connections are closed.
This model is suitable if having an open database connection for each user exceeds the capabilities of your database server. For 30 users connecting to the FireBird database, I do not think this will be required.
source share