[SqueakDBX] Re: [Seaside] Increasing the performances of a Seaside application

[Mariano Martinez Peck]

On Sun, May 29, 2011 at 1:54 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
> On Sun, May 29, 2011 at 10:55 AM, Philippe Marschall <
> philippe.marschall at gmail.com> wrote:
>
>> 2011/5/28 Mariano Martinez Peck <marianopeck at gmail.com>:
>> >
>> >>
>> >> > What are the errors that I must avoid making ?
>> >>
>> >> AFAIK SqueakDBX uses FFI which to my understanding means that it calls
>> >> block the entire VM. That reduces the amount of concurrency a single
>> >> image can handle. It also makes a connection pool more important.
>> >>
>> >
>> > Yes, FFI blocks the whole VM while a functions is being called. However,
>> if
>> > and only if the database client library supports asynchronous queries,
>> > SqueakDBX will work asynchronously. Basically, we do a loop where we ask
>> the
>> > backend if the query was ready. If it was not, we do a yield (we let
>> other
>> > process of the image to run) and then continue the loop.
>>
>> How do you avoid turning this into busy awaiting and still manage to
>> get woken up when data is available?
>>
>>
> What we do is
>

gmail shortcuts...

What we do is:

DBXBackend >> processNextResultSet: aConnection querySettings:
aQuerySettings
    "Gets the next resultSet of the query. Depending on the type of query,
it will return a DBXResult or DBXResultSet.
    If there is a timeout, it will cicle till this is finished."
    | returnCode |
    [self
        nextResultSet: aConnection
        querySettings: aQuerySettings
        onReturn: [:handle :code |
            returnCode := code.
            code = OpenDBX resultWithRows
                ifTrue: [ ^ self processResultWithRows: aConnection
                     resultHandle: handle
                    querySettings: aQuerySettings].
            code = OpenDBX resultWithoutRows
                ifTrue: [ ^ self processResultWithoutRows: aConnection
                     resultHandle: handle
                     querySettings: aQuerySettings].
            code = OpenDBX resultDone ifTrue: [^ nil].

            (code = OpenDBX resultTimeout) ifTrue: [ (Delay forMilliseconds:
(aQuerySettings timeout asMiliseconds)) wait  ].

            ]]     doWhileTrue: [returnCode = OpenDBX resultTimeout].

        OpenDBXDriverError signal: 'Uknown problem with executeStatement'.



so....that is the ugly part of dbx... the method
#nextResultSet:querySettings:onReturn:   basically answers what the backend
answers to:

OpenDBX current
                apiQueryResult: aConnection handle
                handle: handleArray
                timeout: aQuerySettings timeoutAsDBXTimeSpec
                chunk: aQuerySettings pageSize.


that answers what we call in the previous method "code". That "code" can
mean "results wtih no row" for example when it was a DDL (a create table for
example), a "result done" when we have finishes iterating all results , and
"result timeout" that means that the query is not yet finished. In this case
we have to always loop until we have one the two previous possibilities.

Non of us is expert with processes and friends so we may be doing something
wrong. If true, please let us know.

Mariano




>
>
>>  Cheers
>> Philippe
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeakdbx/attachments/20110529/b5988be7/attachment.htm