This shows you the differences between two versions of the page.
| — |
knowhow:connections [2010/02/07 07:21] (current) Tomas Straupis created |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ===== Description ===== | ||
| + | In order to increase stability of TOra - so that it does not freeze if a connection takes too long, or crash if it never returned - connection pooling mechanism was introduced. It means that for one opened TOra there is more than one database session opened. They are reused in different calls to database and time is not wasted to open/close sessions each time main connection is busy and another session is needed. | ||
| + | |||
| + | Note that //mysql// and //postgres// need a second connection just to cancel queries, for example. | ||
| + | |||
| + | Connection pool is also taking care on application level that database sessions do not time out (tcp keep alives don't always work). It's configurable in the preferences if you don't like this behaviour. | ||
| + | |||
| + | ===== Classes ===== | ||
| + | |||
| + | * **toConnection** - abstract database details (name of provider: oracle, mysql, postgres; datatypes used etc.), managing logging in and stuff like that. | ||
| + | * **toQuery** - a physical database connection. | ||
| + | |||
| + | It means that if you need to use one particular database session for a number of different calls you need to have one instance of //toQuery//. In all other cases //toQuery// instance can be created for each call thus possibly using different database sessions. | ||