Subject | Re: [firebird-support] Roles and connection pooling |
---|---|
Author | Thomas Steinmaurer |
Post date | 2012-01-18T11:55:45Z |
Hi Nols,
I don't know UniDACs connection pooling implementation, but I think the
key here is how capable UniDAC is to check if your connection object
request is the same compared to an already available connection object
in the pool. If it doesn't take the role into account, then you might
get an existing connection object from the pool with a previously
different role.
You could use the TraceAPI with the "log_connection" trace configuration
parameter to inspect what's actually hitting the Firebird server when
establishing a database connection.
--
With regards,
Thomas Steinmaurer (^TS^)
Firebird Technology Evangelist
http://www.upscene.com/
http://www.firebirdsql.org/en/firebird-foundation/
> I'm using FB 2.5 Super Server, Delphi7, UniDac database drivers and the IntraWeb/TMSIntraweb components.Interesting question.
>
> With connection pooling, one's application (a web application in my case) typically open a pool of connections to the database. A thread then use a connection from the available pool of connections, locks it, execute some SQL operations and unlock the connection.
>
> My typical code of establishing a connection is:
>
> procedure TDataModule1.OpenDatabase;
> begin
> if IsLibrary then
> DBServer := '127.0.0.1'
> else
> DBServer := 'LocalHost';
>
> try
> with UniConnection1 do
> begin
> Disconnect;
> ProviderName := 'InterBase';
> Server := DBServer;
> loginPrompt := false;
> Database := DBName;
> Username := DBUser;
> Password := DBPassword;
> SpecificOptions.Values['role'] := DBRole;
>
> try
> Connected := true;
> except
> raise Exception.Create('Can''t logon with supplied User ID, Role and Password');
> end;
> end;
> except
> raise;
> end;
> end;
>
>
> The question is: If a user log in by using some (restricted) role, will this pooled connection still be able to serve users in other (less restricted) roles?
I don't know UniDACs connection pooling implementation, but I think the
key here is how capable UniDAC is to check if your connection object
request is the same compared to an already available connection object
in the pool. If it doesn't take the role into account, then you might
get an existing connection object from the pool with a previously
different role.
You could use the TraceAPI with the "log_connection" trace configuration
parameter to inspect what's actually hitting the Firebird server when
establishing a database connection.
--
With regards,
Thomas Steinmaurer (^TS^)
Firebird Technology Evangelist
http://www.upscene.com/
http://www.firebirdsql.org/en/firebird-foundation/