Re: [Modeling-users] Database Connections

[Duncan M. <py...@ad...>]

On Aug 7, 2004, at 11:34 AM, Sebastien Bigaret wrote:

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

Awesome.

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

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?


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

Thanks for your help! I'm sure this will be a good one for the 
archives, too... lots of session-driven apps out there that can benefit 
from Modeling...

d