0

Today:

I continue to work on an application, which, constantly creates and closes a LOT of (sql) connections to the same (Oracle) database, using the same credentials running very basic selects, updates and inserts.

Currently, a singleton CustomConnectionManager checks in its pool to see if any CustomConnectors are available to be given out. Once given out they may be closed by the client. Upon close() the underlying SQLConnection (created and maintained by the CustomConnector) is also closed. If CustomConnector is unavailable, new CustomConnector is created.

The good thing about this is that ultimately SQLConnection remains closed after each use, however, very little reuse is going on as the value lies in SQLConnection not in CustomConnector.

Since all users of the system will connect to the same database, the same single connection may be used to accommodate all requests. Original solution that created new Connectors upon each request seems very wasteful.

Proposed:

singleton CustomConnectionManager will maintain 2 queues:

  • a queue of available CustomConnector, each of which will maintain it's own SQLConnection and
  • a queue of inUse CustomConnectors. Upon request new CustomConnector will be created and given out.

Client interaction only happens with the singleton CustomConnectionManager.

When new connection is needed, manager creates it, gives it out to client and places it in inUse queue. When client is done using the connection, instead of closing it, client will .markConnectorAvailable(), which would put it back into the availableConnectors queue ( Client will no longer be able to control underlying SQLConnection)

Question 1: What do you think? Will this work? Is there an existing solution that already does this well?

Question 2: If proposed approach is not a complete waste, what is a good point for CustomConnector's to close it's SQLConnections?

4

1 回答 1

0

那就是连接池。ADO.Net 在设定的时间内没有使用会杀死它们(可以在连接字符串中设置,(我记得默认是两分钟。)。

于 2012-05-09T00:46:29.483 回答