In WildFly 11 the connection pool have a property "Allow multiple users" that basically "Specifies if multiple users will access the datasource through the getConnection(user, password) method and hence if the internal pool type should account for that".
Probably you should look if that works for you.
Jorge Solórzano
On Wed, Nov 1, 2017 at 6:55 AM, Dave Cramer <pg@fastcrypt.com> wrote:
yes, and with a bit of work you should be able to port the changes over to the current pgbouncer
On 31/10/2017 12:56, Álvaro Hernández Tortosa wrote:
On 31/10/17 10:08, Achilleas Mantzios wrote:
Hello Vladimir, thanx
On 31/10/2017 10:30, Vladimir Sitnikov wrote:
Achilleas>So if say we need 5 connections max for the most complex app to work, and we have 200 users, then at peak time, the total number of connections would have to be raised to 1000.
Pools can shrink, so you do not have to raise total number of connections to 1000 unless you truly expect 1000 concurrent connections.
I know, but we still risk having our max_connections exceeded. And this is not scaleable.
That's true, but if you have a pgbouncer in front of PostgreSQL (you should) and the connections are used wisely (i.e. they are returned as soon as they finish the job, they don't sit idle) this is no longer a problem.
That would be a blessing if pgbouncer supported LDAP .
Álvaro
-- Achilleas Mantzios IT DEV Lead IT DEPT Dynacom Tankers Mgmt
