Re: Database Connections

Duncan McGreggor <[email protected]> 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.
> 
> However, what happens when I use EditingContextSessioning? It seems to create
> 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 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?
> >
> > 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?
> 
> 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 without
> 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ébastien.



-------------------------------------------------------
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