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

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