Re: Database Connections

Duncan McGreggor <[email protected]> Fri, 6 Aug 2004 18:50:15 -0400
Newsgroups gmane.comp.python.modeling
Message-ID <[email protected]>
On Aug 4, 2004, at 6:54 PM, Sebastien Bigaret wrote:

>
> And BTW, I suspect that if you've already given a try to the
> ECSessioning module, or thought aboyut using it, then all the sessions
> probably lie in the same process --or it would have been useless.
>
>   So, now, I see the moment coming where you'll ask whether it's
>   possible to have a dedicated db-connection per EC; is that it?

Yes, that was the direction I was heading with my questions. However, 
this may not truly be the business need. More details:

* There are probably never (famous last words) going to be more than 20 
simultaneous
* When a user logs in, a connection to the database will be opened for 
them (via an editing context)
* This connection need to be kept open for this user until their 
session expires in order to minimize the overhead of stale open 
database connections on the database server

Does/can the EC keep an open connection to the database?

> You also wrote:
>> What they meant by pooling is not what Oracle developers usually mean;
>> they want to be sure that for every HTTP Session, and all of it's HTTP
>> requests, there is a single connection to the database that is reused
>> for the entire length of the session lifetime.
>
>   In other words, does it mean that "for each session's EC there exists
>   one and only one connection to the db"??

Yes. That makes sense, though, right? I mean, if there is a web app 
with which a user could potentially make hundreds of queries to the 
database, we'd want to keep their connection open instead of pounding 
the db with new connections, right?

> If this is the case, then we'll need an other ObjectStoreCoordinator,
> assigning a dedicated DBContext to each EC... Hmmm, just thinking 
> loudly
> here, okay, I'll wait til you confirm the need for such a feature.

How much work is entailed in this? What would the other OSC do?



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com