Re: [Modeling-users] Database Connections

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

Duncan McGreggor <py...@ad...> wrote:
> Since the basic requirements were to have minimal connects to the database
> server, the default behaviour of keeping the connection open is just fine.
>=20
> However, what happens when I use EditingContextSessioning? It seems to cr=
eate
> an EC keyed off a session id. Will that keep one complete editing context=
 per
> user session (and thus one opened database connection per session)? or am=
 I
> missing something?

By default ECSessioning creates an EC per session id, right --but then,
each EC has the same parent ObjectStore, an ObjectStoreCoordinator by
default, which in turn forwards the request (e.g. a fetch) to the
appropriate elements underneath it.

In a word: you get as much ECs as you want, but only one DB-connection
is opened (and left opened).

> >>> If this is the case, then we'll need an other ObjectStoreCoordinator,
> >>> assigning a dedicated DBContext to each EC... Hmmm, just thinking lou=
dly
> >>> 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?
> >
> > 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?
>=20
> There is no business need or user demand for this app that will require
> super-speeds and concurrent queries per session, so I think it's fine wit=
hout
> going through this trouble... yet ;-)

Fine :)  but that's an idea we should keep in mind.  That will probably
be requested in the future.

  Oh and BTW, Soif hasn't made the remark yet ;) but there is a
  potential problem with caching, since there is no way for now to
  "forget" an object and its corresponding snapshot --except by deleting
  all ECs that reference it.  Keep that in mind, I'll get back on the
  subject before the next release I guess.

-- S=E9bastien.