We are already in the process of making n + connections and the number of simultaneous builds has bee, simultaneous

We are already in the process of making n + connections and the number of simultaneous builds has bee, simultaneous

Simultaneous-build-throttle:
This is the maximum number of connections we can be building at any one time.
That is, the number of new connections that have been requested but aren't yet available for use.
Because connections can be built using more than one thread (for instance, when they are built on demand)
And it takes a finite time between deciding to build the connection and it becoming available we need some
Way of ensuring that a lot of threads don't all decide to build a connection at once. (We cocould solve this in
Smarter way-and indeed we will one day) Default is 10.
It refers to the maximum number of connections that can be established at any time, that is, the number of new connections that have been requested but are not available. Because connections can be established using multiple threads,
It may take some time to establish a connection. Therefore, we need some methods to avoid a large number of threads trying to establish a connection at the same time.
(We should have found a smarter way to solve this problem. We will find it one day.) The default value is 10.
When I used 140 users for stress testing, I found that there were more than 10 requests requiring simultaneous connection. When the number of requests exceeds the limit, the connection fails.
Therefore, the conclusion is that when the Database Concurrent connection may be relatively high, this value should be set to a larger value.
If the concurrent request is high, the possible bug is

Caused by: java. SQL. SQLException: We are already in the process of making 11 connections and the number of simultaneous builds has been throttled to 10

Maximum-active-time:
If the housekeeper comes has ss a thread that has been active for longer than this then it will kill it. So make sure you set this to a number bigger than your slowest expected response! Default is 5 minutes.
If the activity time of a thread exceeds this value, the thread will be killed. Therefore, make sure that this value is set to be longer than the slowest response time. The default value is 5 minutes. The daemon will kill unnecessary available threads in the connection pool (unused threads that have exceeded this time), and the number of connections to be retained is the number specified by minimum-connection-count. The daemon checks the time interval specified by the house-keeping-sleep-time parameter.

Maximum-connection-lifetime:
The maximum amount of time that a connection exists for before it is killed (milliseconds). Default is 4 hours.
The maximum lifetime of a connection (unit: milliseconds). If the maximum lifetime is exceeded, the connection is killed. The default value is 4 hours.

Overload-without-refusal-lifetime:
This helps us determine the pool status. If we have refused a connection within this threshold (milliseconds) then we are overloaded. Default is 60 seconds.
This parameter helps us determine the status of the connection pool. If a connection is rejected within the time threshold (in milliseconds), the connection is deemed to be overloaded. The default value is 60.

Alias: alias of the Data Source

Driver-url: url connection string. the user name and password must be determined.

Driver-class: driver name

Username: User Name (proxool is not used, but cannot be used)

Password: password (proxool is not used, but cannot be used)

Maximum-new-connections: the maximum number of requests that can be allocated without idle connections in the queue. User connections that exceed the number of requests will not be accepted.

Test-before-use:

If you set this to true then each connection is tested (with whatever is defined in house-keeping-test-SQL) before being served. if a connection fails then it is discarded and another one is picked. if all connections fail a new one is built. if that one fails then you get an SQLException saying so.

If the connection pool is running and you cannot connect to the database due to a network or database fault, the connection will still be unavailable because the connection is permanently saved in the connection pool after it returns to normal, in this case, connections in the connection pool are actually bad connections. How can I enable the connection pool to automatically reconnect and clear these bad connections? You only need to configure the test-before-use parameter, that is, check whether the connection is available every time you retrieve the connection, so that the connection pool can automatically reconnect after the fault is restored.

Note that the autoReconnect = true parameter must be added to the connection parameters of the Mysql database. Otherwise, the connection cannot be reconnected even if the test-before-use parameter is enabled!

 

Fatal-SQL-exception:

It is a comma-separated information segment. when an SQL exception occurs, its exception information will be compared with this information segment. if this Exception exists in the segment, it is considered a Fatal error (Fatal SQL Exception ). in this case, the database connection will be abandoned. whatever happens, this exception will be thrown to the consumer. you 'd better configure a different exception to throw.

Fatal-SQL-exception-wrapper-class:

As mentioned above, you 'd better configure a different exception to throw. with this attribute, you can wrap SQLException to make it another exception. this exception may inherit SQLException or the inherited word RuntimeException. proxool comes with two implementations: 'org. logicalcobwebs. proxool. fatalSQLException 'and 'org. logicalcobwebs. proxool. fatalruntimeexception '. the latter is more suitable.

House-keeping-sleep-time:

The proxool automatically detects the time interval (in milliseconds) of each connection status. When idle connections are detected, the system immediately recycles them. The destruction time-out period is 30 seconds by default)

The longest time for house keeper to keep the thread in sleep state. The role of house keeper is to check the status of each connection and determine whether to destroy or create it.

House-keeping-test-SQL:

If an idle database connection is found, house keeper will use this statement for testing. This statement should be executed very quickly. If it is not defined, the test process will be ignored.

Generally, mysql can select SYSDATE, and Oracle can select sysdate from dual or select 1 from dual.

Injectable-connection-interface: method that allows proxool to implement the connection object to be proxy.

Injectable-statement-interface: Allows proxool to implement the Statement object method to be proxies.

Injectable-prepared-statement-interface: allows the proxool tool to implement the PreparedStatement object method to be proxy.

Injectable-callable-statement-interface: allows the proxool tool to implement the CallableStatement object method to be proxy.

Jmx: omitted

Jmx-agent-id: omitted

Jndi-name: name of the Data Source

Maximum-active-time: if housekeeper detects that the activity time of a thread is greater than this value. it will kill this thread. so check the bandwidth of your server. set a proper value. the default value is 5 minutes.

Maximum-connection-count:

The maximum number of connections to the database. Default is 15.

Maximum number of database connections. The default value is 15.

Minimum-connection-count: minimum number of database connections. The default value is 5.

Prototype-count:

If there are fewer than this number of connections available then we will build some more (assuming the maximum-connection-count is not exceeded ). for example. of we have 3 active connections and 2 available, but our prototype-count is 4 then it will attempt to build another 2. this differs from minimum-connection-count because it takes into account the number of active connections. minimum-connection-count is absolute and doesn't care how these are in use. prototype-count is the number of spare connections it strives to keep over and above the ones that are currently active. default is 0.

Number of available connections in the connection pool. if the number of connections in the current connection pool is less than this value. the new connection will be established (assuming that the maximum number of available connections is not exceeded ). for example. we have three active connections and two available connections, and our prototype-count is 4, the database connection pool will try to establish another two connections. this is different from minimum-connection-count. minimum-connection-count counts the active connections. prototype-count is the number of spare connections.

Recently-started-threshold: omitted

Statistics: connection pool usage statistics. Parameter "10 s, 1 m, 1d"

Statistics-log-level: type of log statistics trail. Parameter "ERROR" or "INFO"

Test-after-use: omitted

Trace: if it is true, each executed SQL statement will be logged during the execution period (DEBUG LEVEL). You can also register a ConnectionListener (see ProxoolFacade) to obtain this information.

Verbose: Detailed information settings. Bool Value