Can some tell me how to use connection pooling with MonetDb? Do I just append these args to the URL "poolminimum=1;poolmaximum=5;"?
No, by itself, the driver does not pool connections. You could use c3p0 (http://www.mchange.com/projects/c3p0/) to create a connection pool for MonetDB JDBC connections. However, please be aware that MonetDB uses optimistic concurrency control and table-level locking, so firing updates at a single table from multiple connections will have an increasing risk of transaction aborts. For reading however, this should be fine.
Related
We are currently using Pgbouncer(installed on database server) for database connection pooling. At the same time we use Npgsql Library which has its own connection pool. I have read recommendations that we should disable pooling in Npgsql and use only Pgbouncer.
There is a performance problem when we disable connection pooling in Npgsql.
According to my test, it takes 100 ms to connect to pgbouncer. Latency to server with PgBouncer is <1ms.
Executing 5 queries with 5 connections will take more than 500ms, which is too much.
Are we using it correct? That connection latency is killing my performance.
I tried to connect to pgbouncer from different server in network and it took from 8 to 22 ms. I am assuming, it is some network issue.
There is no reason to disable connection pooling in Npgsql unless you have errors or compatibility issues.
PGBouncer helps with scalability by handling many more concurrent connections at once without overloading Postgres (which creates a process for each new connection). This does not mean that creating new connections is any faster, so it's better to reuse an existing pool.
Npgsql would maintain a pool of connections from your application to pgbouncer, and pgbouncer would have a pool of connections from itself to Postgres. This works fine and will ensure both network hops are as efficient as possible.
I'm building an advanced RoR application with several instances of database connections running concurrently. However I'm still looking for answers for the following,
Does the connection handler automatically add a connection into the pool once its established? Like the following way,
ActiveRecord::Base.establish_connection(spec)
When would it disconnect the active connection if there's no activity for a while? Or should it be manually disconnected.
Are there any other alternatives to disconnecting the database connection like the following,
ActiveRecord::Base.remove_connection(connection_object)
How can I increase the pool size which could be for different database adapters.
Looking forward to some tips.
If a connection is 'inactive' I guess the Weblogic internal data source manager should recover the connection. Why should 'Inactive Connection Timeout' be a configurable parameter. Is there any use case which requires WL to wait for certain period before an inactive connection is recovered?
Thanks in advance.
This variation could occur depending on what downstream systems are doing, or where a system is sometimes under load and not able to respond in an adequate period of time
A leaked connection is a connection that was not properly returned to the connection pool in the data source. To automatically recover leaked connections, you can specify a value for Inactive Connection Timeout on the JDBC Data Source. ( Configuration: Connection Pool page in the Administration Console.) When you set a value for Inactive Connection Timeout, WebLogic Server forcibly returns a connection to the data source when there is no activity on a reserved connection for the number of seconds that you specify. When set to 0 (the default value), this feature is turned off.
After digging into this.. specific to question "Why should it be configurable..", because by default this feature is turned off, you can turn it on if you believe that the application for some reason is not returning connections back to the pool, i.e.
leaking connections. Depending on the application use cases and the amount of resource leakage, one could set the duration. IOW, you don't want to timeout connections too quickly, because it will force the app server to have to recreate those on next need or cause unnecessary errors. But if the application is leaking a lot of connections, then you can tighten the duration so it keeps cleaning up.
So I have a connection pool setup. Which is great and all since I have an application that really needs it. However what I would like to know is if it is possible to share this connection pool with other J2SE apps? Would this even be worth it, as opposed to creating a connection pool based on each apps needs? If it would be prudent, how can I accomplish this?
It is not hard having connection pools in a single JVM doing multiple things - that is what applications servers do everyday (using JNDI to throw objects across classloaders)
The interesting part is when you have the connection pool in a separate JVM from the client code needing it, as this does not immediately allow simply asking for and getting a connection from the pool and returning it afterwards.
Basically you have two options:
Doing remote requests for all your JDBC commands over the network. This will most likely mean that the data will travel over the network twice, from the database to the connection pool, and then from the connection pool to your application. If the database connections are very expensive objects then this might be a viable solution.
Use RMI to get the connection object from the connection pool JVM to your own machine. This is a very expensive operation, but can as far as I know include the actual driver classes, allowing your connection pool to provide connections to databases not known to your application JVM. To me this would only make sense if the database connections were ridiculoulusly expensive or it was a requirement to be able to support additional databases after deployment without changing the original deployments.
Note that the primary reason for having connection pools at all is because connections are expensive to create, use shortly and then discard. Some databases more than others, e.g. MySQl is (or was when I tried) very cheap so it might be the simplest just to do that.
So. First of all: Measure what your connection pool buys you in time, and then consider if it is worth your while to centralize this further.
Which use of connection management is better while developing a windows based application which uses a Database as its data store? What about web-based applications?
when user loads the first form of an application, the global
connection opens and on closing the last form of the application
the connection closes and disposes.
for each form within the application, there is a local connection
(form scope) and when user wants to perform an operation like
insert, update, delete, search, ... the application uses the
connection and by unloading the form the connection also closes and
disposes.
for every operation within a form of an application, there is a
local connection (procedure scope) and when user wants to perform
an operation like insert, update, delete, search, ... the
application uses procedure connection and at the end of every
procedure within the form, the connection also closes and disposes.
Go with #3
You should try to only ever keep connections open for just as long as is required.
Also have a look at
Understanding Connection Pooling
SQL Server Connection Pooling
(ADO.NET)
Connecting to a database server
typically consists of several
time-consuming steps. A physical
channel such as a socket or a named
pipe must be established, the initial
handshake with the server must occur,
the connection string information must
be parsed, the connection must be
authenticated by the server, checks
must be run for enlisting in the
current transaction, and so on.
In practice, most applications use
only one or a few different
configurations for connections. This
means that during application
execution, many identical connections
will be repeatedly opened and closed.
To minimize the cost of opening
connections, ADO.NET uses an
optimization technique called
connection pooling.
Connection pooling reduces the number
of times that new connections must be
opened. The pooler maintains ownership
of the physical connection. It manages
connections by keeping alive a set of
active connections for each given
connection configuration. Whenever a
user calls Open on a connection, the
pooler looks for an available
connection in the pool. If a pooled
connection is available, it returns it
to the caller instead of opening a new
connection. When the application calls
Close on the connection, the pooler
returns it to the pooled set of active
connections instead of closing it.
Once the connection is returned to the
pool, it is ready to be reused on the
next Open call.
This is quite a broad question. But usually, for any database server and application environment, opening and keeping a new connection is an expensive operation. That's why you definitely don't want to open multiple connections from a single client, and should stick to process-scope for connections.
In a desktop application using a database server, strategy for handling it's single connection depends a lot on the DB usage pattern. Say, if the app reads or writes something a lot within 5 minutes, and then just does nothing with the DB for hours, it makes no sense to keep the connection open all the time (assuming there are many other clients). You may introduce some kind of time-out for closing a connection.
The Web server situation depends a lot on the used technology. Say, in PHP every request is a "fresh start" WRT database connection. You open and close a connection for each mouse click. While popular Java application servers have DB connections pool, reusing the same connection instances for many HTTP request handling threads.