RE: Oracle or PostGreSQL connection pool
Message: 24 Date: Tue, 18 Jan 2000 09:48:24 +0000 (GMT) From: Oleg Broytmann Reply-To: phd@phd.russ.ru To: Zope Mailing List Subject: Re: [Zope] Oracle or PostGreSQL connection pool
Hi!
Is there any way to implement the following thing?
I have an Oracle database, and by design every user that logs into the site will be connected to the DB with his/her login/password (that is, his/her Oracle login/password is the same as for WWW).
It sounds strange. Orcale is very poor of managing connections. The entire transaction process monitor (TPM) business earns of its revenue from this fact. A TPM (just like ZOracleDA) uses its own username/password to connect to a database. This is the only way to maintain an efficient connection pooling strategy. I am very curios of your rationale of thinking of this usage of Oracle.
I am considering using Zope for the site, but the question is - how can I create one ZOracleDA connection for every user, and how can I use diferent connections for different users?
Cuurently the site is in the process of development, and we are considering different techiniques. Zope is one of them; another possible solution will be CGIs + small server (on WWW side) that will handle long-time pool of connections from WWW to Oracle (CGIs will not be connected to Oracle directly, but will connect to the server, use a connection from the pool, etc.)
I do not understand. If you want to use a separate connection for each user, you will not have any pool. I think we can speak of a pool when each connection in the pool has the same database(SID)/user/password. I'd really interested in your goals with this architecture. I read a lot of your mails, Oleg, and I liked them very much, you must have some trick here :-). NM
On Tue, 18 Jan 2000, Nemeth Miklos wrote:
I have an Oracle database, and by design every user that logs into the site will be connected to the DB with his/her login/password (that is, his/her Oracle login/password is the same as for WWW).
It sounds strange. Orcale is very poor of managing connections. The entire transaction process monitor (TPM) business earns of its revenue from this fact. A TPM (just like ZOracleDA) uses its own username/password to connect to a database. This is the only way to maintain an efficient connection pooling strategy. I am very curios of your rationale of thinking of this usage of Oracle.
Not my solution, but database programmers/admins.
I am considering using Zope for the site, but the question is - how can I create one ZOracleDA connection for every user, and how can I use diferent connections for different users?
I do not understand. If you want to use a separate connection for each user, you will not have any pool. I think we can speak of a pool when each connection in the pool has the same database(SID)/user/password. I'd really interested in your goals with this architecture.
Currently there are a number of CGIs. Every CGI reads login/password from cookies, connects to the database, does its job and disconnects (and update cookie expiration time). I want to avoid this connection/disconnection. So I think to have a server (home-grown or Zope) which opens connectins for every user and leave it open for a longer time.
I read a lot of your mails, Oleg, and I liked them very much, you must
Thanks! :)
have some trick here :-).
They (DB programmers/admins) calls it "security". Oleg. ---- Oleg Broytmann Foundation for Effective Policies phd@phd.russ.ru Programmers don't die, they just GOSUB without RETURN.
Oleg Broytmann wrote:
I am considering using Zope for the site, but the question is - how can I create one ZOracleDA connection for every user, and how can I use diferent connections for different users?
I do not understand. If you want to use a separate connection for each user, you will not have any pool. I think we can speak of a pool when each connection in the pool has the same database(SID)/user/password. I'd really interested in your goals with this architecture.
Currently there are a number of CGIs. Every CGI reads login/password from cookies, connects to the database, does its job and disconnects (and update cookie expiration time). I want to avoid this connection/disconnection. So I think to have a server (home-grown or Zope) which opens connectins for every user and leave it open for a longer time.
Now I know! I think building a pooling server for this architecture is a big job and the outcom may not deseve the effort.
have some trick here :-).
They (DB programmers/admins) calls it "security".
Sounds interesting. Database usernames and passwords stored in cookies. I worked for a telecom corporation last year as a "programmer", if I'd just even mention this to the system administrator responsible of data and intenret security of this corp, he would surely bite off my head. NM
On Wed, 19 Jan 2000, Nemeth Miklos wrote:
Currently there are a number of CGIs. Every CGI reads login/password from cookies, connects to the database, does its job and disconnects (and update cookie expiration time). I want to avoid this connection/disconnection. So I think to have a server (home-grown or Zope) which opens connectins for every user and leave it open for a longer time.
Now I know! I think building a pooling server for this architecture is a big job
Sure! That's why I consider to use Zope and hack special kind of connection.
and the outcom may not deseve the effort.
It is arguable...
They (DB programmers/admins) calls it "security".
Sounds interesting. Database usernames and passwords stored in cookies. I worked
Nice point. Of course, I think about it all the time.
for a telecom corporation last year as a "programmer", if I'd just even mention this to the system administrator responsible of data and intenret security of this corp, he would surely bite off my head.
I think I'll do a kind of "session", and will store session data somewhere on a server, and store Session ID in cookie. Of course, with Zope I'll use ready FSSession. Oleg. ---- Oleg Broytmann Foundation for Effective Policies phd@phd.russ.ru Programmers don't die, they just GOSUB without RETURN.
participants (2)
-
Nemeth Miklos -
Oleg Broytmann