Scenario 1 - You leave "Pool Data Connections" unchecked in the Intraweb Application Wizard
In this scenario the wizard creates a ServerController
, a UserSession
but not a DataModule
. You place your database, session and dataset components on the UserSession
.
Whenever a new user connects to your website a new instance of the UserSession
is created and a connection to the database is made. When the ServerController.SessionTimeOut
expires due to user inactivity the UserSession
is destroyed and that particular connection to the database is severed.
For 30 concurrent users this model will probably be fine for you and should guarantee that all database connections will be severed when the website is not in use.
Scenario 2 - You check "Pool Data Connections" in the Intraweb Application Wizard
As well as the ServerController
and the UserSession
the wizard will create an empty DataModule
. You place your database, session and dataset components on the DataModule
.
The ServerModule
has a TIWDataModulePool
component on it which has PoolCount
property.
When your application starts it creates PoolCount
instances of the DataModule
each one of which makes a connection to the database. As your pages require database access they call LockDataModule
and UnlockDataModule
to temporarily make use of one of the DataModule
instances from the pool.
When your application closes the DataModule
instances in the pool are destroyed and their connections to the database are closed.
This model is appropriate when having an open database connection per user would exceed the capabilities of your database server. For just 30 users connecting to a FireBird database I don't believe it would be required.