[Monetdb-developers] Monetdb-developers Digest, Vol 22, Issue 4

Ying Zhang Y.Zhang at cwi.nl
Fri Mar 28 12:36:55 CET 2008


On Mar 28, 2008, at 11:53 , Peter Boncz wrote:
> Hi Maurice,
>
> That is not possible.. without adding extensions such as proposed in  
> XQueryP or
> XQuery-Bang.
>
> Why is it that running the update followed by a query is not  
> acceptable?
>
> Another idea is to use fn:put() in the update, and then just a HTTP  
> GET to get
> the XML result out. That is still a single query.
>

Hi Peter,

Do we treat fn:put() as an updating function?  If not, this won't  
work, as fn:put() will be executed before the update list is applied,  
I think.

I was thinking that what Maurice asks is very similar with what X-Hive  
does in a transaction.  I'm wondering if it might be possible to  
support?


Jennie








> Peter
>
>> -----Original Message-----
>> From: Keulen, M. van (Maurice) [mailto:m.vankeulen at utwente.nl]
>> Sent: Friday, March 28, 2008 11:29 AM
>> To: Ying Zhang
>> Cc: P.Boncz at cwi.nl; monetdb-developers at lists.sourceforge.net
>> Subject: Re: Monetdb-developers Digest, Vol 22, Issue 4
>>
>>
>> Ying Zhang wrote:
>>> Hi Maurice,
>>>
>>> Stupid me.  I only described how the current XRPC
>> implementation is,
>>> but forgot to mention the ongoing work.
>>>
>>> On Mar 28, 2008, at 09:35 , Keulen, M. van (Maurice) wrote:
>>>> Hi Peter,
>>>>
>>>> Does it also mean that if I send a stream of messages to
>> one server
>>>> that all carry the same request-ID without waiting for a
>> result of a
>>>> message before sending out the next, that all are handled in the
>>>> correct order and each is handled after completion of the previous
>>>> one? In that case, it meets all my requirements. In fact, it gives
>>>> much more than I ask for :-) I definitely like to follow any
>>>> developments for this one!
>>>
>>> This can be easily supported by adding a sequence number to each
>>> request message, I think.
>>>
>>> But, if you have an updating request, and then a read-only
>> request, do
>>> you then want to make the updates made by the first request
>> visible to
>>> the second request?
>>>
>> Comparing it to the behaviour of a relational DBMS doing 'begin
>> transaction ; update ; select ; commit' then, yes, I expect
>> the effect
>> of the update to be visible for the select, but not visible
>> to select's
>> done in other concurrently running transactions (the I of
>> isolation in
>> ACID).
>>
>> Maurice.
>>
>> -- 
>> ----------------------------------------------------------------------
>> Dr.Ir. M. van Keulen - Assistant Professor, Data Management  
>> Technology
>> Univ. of Twente, Dept of EEMCS, POBox 217, 7500 AE Enschede,
>> Netherlands
>> Email: m.vankeulen at utwente.nl, Phone: +31 534893688, Fax: +31
>> 534892927
>> Room: ZI 3039, WWW: http://www.cs.utwente.nl/~keulen
>>
>





More information about the developers-list mailing list