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