Re: [Modeling-users] Database Connections

[Sebastien B. <sbi...@us...>]

Duncan McGreggor <py...@ad...> wrote:
[snip]
> Yes, that was the direction I was heading with my questions. However, this
> may not truly be the business need. More details:
>=20
> * 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 th=
em
> (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 connecti=
ons
> on the database server
>=20
> Does/can the EC keep an open connection to the database?

Fine. The framework keeps it opened by default --see documentation for
MDL_TRANSIENT_DB_CONNECTION at
http://modeling.sourceforge.net/UserGuide/env-vars-core.html
(the pdf is still wrong, I updated that section yesterday)

> > 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"??
>=20
> 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 n=
ew
> connections, right?

Yes --but the need to keep a database connection opened, or the need to
have an opened database connection per user/session is quite different.

> > 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.
>=20
> How much work is entailed in this? What would the other OSC do?

It would assign specific elements of the Database (DBContext, DBChannel)
and Adaptor (AdaptorContext, AdaprotChannel) layers per EC.  At least,
that's what I initially thought. There may be another way to ensure
different fetchs could run concurrently --but if you can accept that any
fecth waits for the running one to finish, it's probably not worth the
effort, or am I still missing something?

-- S=E9bastien.