On Wed, Dec 22, 2010 at 12:16 PM, Scott Burson <[email protected]> wrote: > On Tue, Dec 21, 2010 at 4:19 AM, Leslie P. Polzer <[email protected]> > 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 > THREAD-PREPARE-STORE
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 request. 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, like 72 hours), and I don't know if it's wise to have thousands of open connections to a database, even if most of them aren't doing anything at any given moment. There's precedent, by the way, for something like CLSQL-Fluid. It's the same idea as synonym streams: delegation of operations on a per-thread basis. I haven't looked at what you've done for the Postmodern store, but if it's the same idea as what I did here, you might need to reconsider. -- Scott -- You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
