Re: Re: CLSQL-Fluid
Scott Burson <gyro@...
2011-12-28 06:52:28 GMT
On Wed, Dec 22, 2010 at 12:16 PM, Scott Burson <gyro@...> wrote:
> On Tue, Dec 21, 2010 at 4:19 AM, Leslie P. Polzer <leslie.polzer@...> wrote:
>> We've discussed this in the context of the upcoming Postmodern store
>> and think it's the right thing to do (provided we abstract it properly
>> so it works with multiple stores).
>> But we need to test and think a bit more about it. It'd be great if
>> you could try this approach in parallel for CLSQL.
> Okay, I took a shot at it. [...]
> The patch is below. Basically there's a new generic function
I don't know if anybody ever tried to use this patch, but I hope not,
because it doesn't work. I mean, it appears to work at first, but in
the end it turns out not to.
The problem is that it opens new connections and binds
*DEFAULT-DATABASE* on a request basis, but that's too fine-grained.
Widgets hold on to view objects across requests. There's also the
CLASS-STORE slot of DATA-EDITOR, whose lifetime is longer than a
I now understand that CLSQL-Fluid represents the right solution
strategy. I considered the approach of associating database
connections with sessions, which I think would also basically work;
the problem, though, is that a busy server could have many thousands
of active sessions (particularly if one cranks up Hunchentoot's
default 30-minute session timeout to something more user-friendly,