Achilleas Mantzios wrote:
> Yes that's the logic. One connection pool per user.
> I find it more clever, fine grained and just better from
> many perspectives (security/auditing/diagnosis/debugging being the main ones).
Too clever by half. What do you do with the pool when a user is logged off
for a few days, then comes back? How many pools will you have when a thousand
users log off and another thousand log on? How many connections will you keep
in each pool? How will the DB engine keep up with all that?
I predict that you will get no increase in security or auditing capability
that couldn't be handled with the conventional "one user per application"
approach, and that diagnosis and debugging will be complicated in some other
way, and that you'll have performance and resource issues.
> We have LDAP based authentication in Jboss. And i [sic] use the very same LDAP server for postgresql authentication
aswell.
> So i [sic] have one point of authentication for both Jboss, PostgreSQL, the very same LDAP server.
> User logs in, and his credentials are delegated to PostgreSQL with *no* involvement of any application code.
> So from a one-user monolithic declarative model we can go now on fully multi sql [sic] user, with *no changes* in the
app,
> or the .EAR configuration!!!
> As we speak i [sic] am testing it with max 4 connections/user.
> Both systems (postgresql [sic], jboss [sic]) support this as is, with just recompilation (postgresql) / configuration
(jboss).
> The main question is twofold: If any one has any theoretical objections to this model,
> and 2nd if anyone has encountered any problems by using this or smth [sic] similar.
--
Lew
Ceci n'est pas une pipe.
