| Subject | Re: Which way of connection is prefered? |
|---|---|
| Author | Adam |
| Post date | 2008-01-10T05:36:44Z |
--- In firebird-support@yahoogroups.com, Magicloud Magiclouds
<magicloud.magiclouds@...> wrote:
the connections for the different engines. What causes unhappy DBAs is
their servers grinding to a halt because of the way they are being used.
1. It takes time and resources to establish a connection.
When you establish a connection (to any DBMS), a number of things
happen. Usually, you have some form of authentication that must take
place, and some caches that get created and resources set aside. This
all takes time.
2. It takes resources to hold a connection open.
There are often caches associated with a connection, and while the
connection is open these resources can not be released.
As Helen pointed out to you, you have different types of applications.
An application that collects data every 30 minutes would probably be
better off establishing connections as needed and closing them when
done. An application that is continuously running queries would be
foolish to use such an approach, because the overhead in connecting
would slow the server.
I would suggest the 'better' approach is to use a connection pool.
Your data abstraction layer manages the connections. When you need to
run a query, you simply grab an existing connection out of the pool.
Once you have finished, return the connection to the pool. If the pool
is empty when you need a connection, a new one is automatically
established and added to the pool. (In fact you can be clever here and
start establishing connections when the pool drops below a few
connections). This is a reasonable compromise. You don't have people
struggling to use the database under the load of unused but still open
connections. The downside of course is that you can not rely so much
on user security implemented within the database based on a generic
connection user.
http://en.wikipedia.org/wiki/Connection_pool
Adam
<magicloud.magiclouds@...> wrote:
>about.
> Hello,
> I think "application requirements" is just one thing to think
> One another thing to think about, which sometimes is more important, isshort
> performance.
> Some databases are not suitable for frequent short connections, and
> some are. Many Oracle DBA would beat the developers using frequent
> connections to death.I disagree with you that the cause of unhappy DBAs is the length of
> While some databases are not suitable for long time idle
> connections, and some are. MySQL is like this.
the connections for the different engines. What causes unhappy DBAs is
their servers grinding to a halt because of the way they are being used.
1. It takes time and resources to establish a connection.
When you establish a connection (to any DBMS), a number of things
happen. Usually, you have some form of authentication that must take
place, and some caches that get created and resources set aside. This
all takes time.
2. It takes resources to hold a connection open.
There are often caches associated with a connection, and while the
connection is open these resources can not be released.
As Helen pointed out to you, you have different types of applications.
An application that collects data every 30 minutes would probably be
better off establishing connections as needed and closing them when
done. An application that is continuously running queries would be
foolish to use such an approach, because the overhead in connecting
would slow the server.
I would suggest the 'better' approach is to use a connection pool.
Your data abstraction layer manages the connections. When you need to
run a query, you simply grab an existing connection out of the pool.
Once you have finished, return the connection to the pool. If the pool
is empty when you need a connection, a new one is automatically
established and added to the pool. (In fact you can be clever here and
start establishing connections when the pool drops below a few
connections). This is a reasonable compromise. You don't have people
struggling to use the database under the load of unused but still open
connections. The downside of course is that you can not rely so much
on user security implemented within the database based on a generic
connection user.
http://en.wikipedia.org/wiki/Connection_pool
Adam
> If Firebird is suitable for both, then everything is OK. If not,automatically if
> then I should think about this when I design the application.
>
> Thanks.
>
> Helen Borrie wrote:
> The "preferred way" is the way that best suits the requirements.
> Applications can be written to time out and log off
> the site has users who carelessly leave a connected
> application unattended for long periods. Doing this might be especially
> useful if the server has limited resources, high peak loads and a
> lot of careless users...
> ./heLen
>