Managing Multiple Sessions
Go Up to Managing database sessions Index
Note: The Borland Database Engine (BDE) has been deprecated, so it will not be enhanced. For instance, BDE will never have Unicode support. You should not undertake new development with BDE. Consider migrating your existing database applications from BDE to dbExpress.
If you create a single application that uses multiple threads to perform database operations, you must create one additional session for each thread. The BDE category on the Tool palette contains a session component that you can place in a data module or on a form at design time.
Warning: When you place a session component, you must also set its SessionName property to a unique value so that it does not conflict with the default session's SessionName property.
Placing a session component at design time presupposes that the number of threads (and therefore sessions) required by the application at run time is static. More likely, however, is that an application needs to create sessions dynamically. To create sessions dynamically, call the OpenSession method of the global Bde.DBTables.Sessions object at run time.
OpenSession requires a single parameter, a name for the session that is unique across all session names for the application. The following code dynamically creates and activates a new session with a uniquely generated name:
Sessions.OpenSession('RunTimeSession' + IntToStr(Sessions.Count + 1));
Sessions->OpenSession("RunTimeSession" + IntToStr(Sessions->Count + 1));
This statement generates a unique name for a new session by retrieving the current number of sessions, and adding one to that value. Note that if you dynamically create and destroy sessions at run time, this example code will not work as expected. Nevertheless, this example illustrates how to use the properties and methods of Sessions to manage multiple sessions.
Sessions is a variable of type TSessionList that is automatically instantiated for BDE-based database applications. You use the properties and methods of Sessions to keep track of multiple sessions in a multithreaded database application. The following table summarizes the properties and methods of the TSessionList component:
TSessionList properties and methods
| Property or Method | Purpose |
|---|---|
|
Count |
Returns the number of sessions, both active and inactive, in the session list. |
|
FindSession |
Searches for a session with a specified name and returns a pointer to it, or nil if there is no session with the specified name. If passed a blank session name, FindSession returns a pointer to the default session, Session. |
|
GetSessionNames |
Populates a string list with the names of all currently instantiated session components. This procedure always adds at least one string, "Default", for the default session. |
|
List |
Returns the session component for a specified session name. If there is no session with the specified name, an exception is raised. |
|
OpenSession |
Creates and activates a new session or reactivates an existing session for a specified session name. |
|
Sessions |
Accesses the session list by ordinal value. |
As an example of using Sessions properties and methods in a multithreaded application, consider what happens when you want to open a database connection. To determine whether a connection already exists, use the Sessions property to walk through each session in the sessions list, starting with the default session. For each session component, examine its Databases property to see whether the database in question is open. If you discover that another thread is already using the desired database, examine the next session in the list.
If an existing thread is not using the database, then you can open the connection within that session.
If, on the other hand, all existing threads are using the database, you must open a new session in which to open another database connection.
If you are replicating a data module that contains a session in a multithreaded application, where each thread contains its own copy of the data module, you can use the AutoSessionName property to make sure that all datasets in the data module use the correct session. Setting AutoSessionName to True causes the session to generate its own unique name dynamically when it is created at run time. It then assigns this name to every dataset in the data module, overriding any explicitly set session names. This ensures that each thread has its own session, and each dataset uses the session in its own data module.