mirror of
https://github.com/asterisk/asterisk.git
synced 2025-10-26 14:27:14 +00:00
321a9b128f
Testing has shown that our usage of UnixODBC is problematic due to bugs within UnixODBC itself as well as the heavy weight cost of connecting and disconnecting database connections, even when pooling is enabled. For users of UnixODBC 2.3.1 and earlier crashes would occur due to insufficient protection of the disconnect operation. This was fixed in UnixODBC 2.3.2 and above. For users of UnixODBC 2.3.3 and higher a slow-down would occur under heavy database use due to repeated connection establishment. A regression is present where on each connection the database configuration is cached again, with the cache growing out of control. The connection pool implementation present in this change helps to mitigate these issues by reducing how much we connect and disconnect database connections. We also solve the issue of crashes under UnixODBC 2.3.1 by defaulting the maximum number of connections to 1, returning us to the previous working behavior. For users who may have a fixed version the maximum concurrent connection limit can be increased helping with performance. The connection pool works by keeping a list of active connections. If the connection limit has not been reached a new connection is established. If the connection limit has been reached then the request waits until a connection becomes available before continuing. ASTERISK-26074 #close ASTERISK-26054 #close Change-Id: I6774bf4bac49a0b30242c76a09c403d2e856ecff
127 lines
4.8 KiB
Plaintext
127 lines
4.8 KiB
Plaintext
;;; odbc setup file
|
|
|
|
; ENV is a global set of environmental variables that will get set.
|
|
; Note that all environmental variables can be seen by all connections,
|
|
; so you can't have different values for different connections.
|
|
[ENV]
|
|
;INFORMIXSERVER => my_special_database
|
|
;INFORMIXDIR => /opt/informix
|
|
;ORACLE_HOME => /home/oracle
|
|
|
|
; All other sections are arbitrary names for database connections.
|
|
|
|
;
|
|
; The context name is what will be used in other configuration files, such
|
|
; as extconfig.conf and func_odbc.conf, to reference this connection.
|
|
[asterisk]
|
|
;
|
|
; Permit disabling sections without needing to comment them out.
|
|
; If not specified, it is assumed the section is enabled.
|
|
enabled => no
|
|
;
|
|
; This value should match an entry in /etc/odbc.ini
|
|
; (or /usr/local/etc/odbc.ini, on FreeBSD and similar systems).
|
|
dsn => asterisk
|
|
;
|
|
; Username for connecting to the database. The user defaults to the context name if unspecified.
|
|
;username => myuser
|
|
;
|
|
; Password for authenticating the user to the database. The default
|
|
; password is blank.
|
|
;password => mypass
|
|
;
|
|
; Build a connection at startup?
|
|
pre-connect => yes
|
|
;
|
|
; What should we execute to ensure that our connection is still alive? The
|
|
; statement should return a non-zero value in the first field of its first
|
|
; record. The default is "select 1".
|
|
;sanitysql => select 1
|
|
;
|
|
; On some databases, the connection times out and a reconnection will be
|
|
; necessary. This setting configures the amount of time a connection
|
|
; may sit idle (in seconds) before a reconnection will be attempted.
|
|
;idlecheck => 3600
|
|
;
|
|
; Should we use a single connection for all queries? Most databases will
|
|
; allow sharing the connection, though Sybase and MS SQL Server will not.
|
|
;share_connections => yes
|
|
;
|
|
; If we aren't sharing connections, what is the maximum number of connections
|
|
; that we should attempt?
|
|
;limit => 5
|
|
;
|
|
; The maximum number of connections to have open at any given time.
|
|
; This defaults to 1 and it is highly recommended to only set this higher
|
|
; if using a version of UnixODBC greater than 2.3.1.
|
|
;max_connections => 20
|
|
;
|
|
; When the channel is destroyed, should any uncommitted open transactions
|
|
; automatically be committed?
|
|
;forcecommit => no
|
|
;
|
|
; How should we perceive data in other transactions within the database?
|
|
; Possible values are read_uncommitted, read_committed, repeatable_read,
|
|
; and serializable. The default is read_committed.
|
|
;isolation => repeatable_read
|
|
;
|
|
; Is the backslash a native escape character? The default is yes, but for
|
|
; MS SQL Server, the answer is no.
|
|
;backslash_is_escape => yes
|
|
;
|
|
; How long (in seconds) should we attempt to connect before considering the
|
|
; connection dead? The default is 10 seconds, but you may wish to reduce it,
|
|
; to increase responsiveness.
|
|
;connect_timeout => 10
|
|
;
|
|
; When a connection fails, how long (in seconds) should we cache that
|
|
; information before we attempt another connection? This increases
|
|
; responsiveness, when a database resource is not working.
|
|
;negative_connection_cache => 300
|
|
|
|
[mysql2]
|
|
enabled => no
|
|
dsn => MySQL-asterisk
|
|
username => myuser
|
|
password => mypass
|
|
pre-connect => yes
|
|
|
|
; Certain servers, such as MS SQL Server and Sybase use the TDS protocol, which
|
|
; limits the number of active queries per connection to 1. By telling res_odbc
|
|
; not to share connections, Asterisk can be made to work with these servers.
|
|
[sqlserver]
|
|
enabled => no
|
|
dsn => mickeysoft
|
|
share_connections => no
|
|
limit => 5
|
|
username => oscar
|
|
password => thegrouch
|
|
pre-connect => yes
|
|
sanitysql => select count(*) from systables
|
|
; forcecommit => no ; Default to committing uncommitted transactions?
|
|
; Note: this is NOT the autocommit flag; this
|
|
; determines the end result of transactions which
|
|
; are not explicitly committed or rolled back. By
|
|
; default, such transactions are rolled back if the
|
|
; call ends without an explicit commit.
|
|
; isolation => read_committed ; Isolation level; supported levels are:
|
|
; read_uncommitted, read_committed, repeatable_read,
|
|
; serializable. Note that not all databases support
|
|
; all isolation levels (e.g. Postgres only supports
|
|
; repeatable_read and serializable). See database
|
|
; documentation for further information.
|
|
;
|
|
; Many databases have a default of '\' to escape special characters. MS SQL
|
|
; Server does not.
|
|
backslash_is_escape => no
|
|
|
|
;
|
|
; If you are having problems with concurrency, please read this note from the
|
|
; mailing lists, regarding UnixODBC:
|
|
;
|
|
; http://lists.digium.com/pipermail/asterisk-dev/2009-February/036539.html
|
|
;
|
|
; In summary, try setting "Threading=2" in the relevant section within your
|
|
; odbcinst.ini.
|
|
;
|