[squeak-dev] Re: Threaded ODBC

Philippe Marschall philippe.marschall at gmail.com
Sun May 11 10:47:29 UTC 2008


2008/5/11, Klaus D. Witzel <klaus.witzel at cobss.com>:
> On Sun, 11 May 2008 12:11:53 +0200, Philippe Marschall wrote:
>
>
> > 2008/5/11, Klaus D. Witzel wrote :
> >
> > > On Sun, 11 May 2008 10:22:46 +0200, Philippe Marschall wrote:
> > >
> > > > 2008/5/11, Klaus D. Witzel wrote:
> > > >
> > > > > On Sat, 10 May 2008 19:45:57 +0200, Rob Rothwell wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I was just wondering if anyone knew what work would be required to
> > > provide
> > > > > a
> > > > > > threaded ODBC connection in Squeak similar to what is available
> for
> > > > > > VisualWorks or Smalltalk/X.  The ability to not freeze the VM
> while
> > > > > running
> > > > > > a query would be very useful for me, but I don't even know where
> to
> > > start.
> > > > > >
> > > > >
> > > > >  Out of curiosity, what would it be that you intend to let the users
> do
> > > > > while longish queries are tickling the db?
> > > > >
> > > >
> > > > If you use Seaside: reply to other requests.
> > > >
> > >
> > >  Sure, goes without saying. *but*what*else* ?
> > >
> >
> > Doing the usual GUI updates (hover, progress bar, whatsoever) so that
> > the application does not appear "frozen".
> >
>
>  We asked the users (releases 1-2 where developed by our "predecessors", we
> did the 3.x release series, the users where *very* well experienced :=
> plagued by DB response time). Guess what they asked for.
>
>  BTW: progress bar update is #fork work.

UI updates in general have to happen in a very specific thread.

> Furthermore, you'll earn credit if
> you can predict the 100% base and the respective increments, of arbitrary db
> queries which are performed on some dedicated server multi-user, predict
> with a small epsilon (not like MS$ does it when they copy/move around
> files).

Progress bars in general have a indeterminate mode for such cases.

> >
> >
> > > > Cheers
> > > > Philippe
> > > >
> > > >
> > > > >  I ask with this background in mind: over several years I headed a
> team
> > > of
> > > > > developers who produced 1.5 releases/year of a
> > > > > (fat+GUI)client<->(shared+fast)db server app with
> > > between 6
> > > > > and 60 GB data etc, 50+ installation sites (institutions with their
> own
> > > db
> > > > > server) and 100+ users, with 98% of the db data being updated over
> night
> > > > > (incrementally). We brought down the app's db response time from
> minutes
> > > to
> > > > > seconds but still never found any reason for using non-blocking
> queries,
> > > > > because nothing much was there that could have been done by the user
> in
> > > the
> > > > > meantime.
> > > > >
> > > > >  Do you just want to see non-freezing queries running or have some
> other
> > > > > reason for that need?
> > > > >
> > > > >  /Klaus
> > > > >
> > > > >
> > > > > > Or, is it a bigger issue than just ODBC, something buried deep
> within
> > > the
> > > > > VM
> > > > > > and/or the FFI?
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Rob
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>
>
>
>



More information about the Squeak-dev mailing list