You're right that server-fields are server-specific, so the Task Server can't 
see other app-server fields. You could take advantage of that: put the real 
work for both queries on the task server so they can both see the same server 
fields. But the ajax request will need to see the result of the task, so use 
the 'result' option to xdmp:spawn to get that. Oddly that option is documented 
at http://docs.marklogic.com/xdmp:eval - but 
http://docs.marklogic.com/xdmp:spawn#spawnresultex shows an example.

I think that's probably the right approach, because it allows you to further 
break up the long-running update into multiple tasks. But I'm puzzled by your 
description of blocking. The way I would structure this would be to load a page 
that doesn't really do anything itself. Once loaded it fires off an async HTTP 
request to start the long-running update task. Then it sits back and polls the 
progress query with more async requests. Given that setup, I can't see why they 
would block each other. Last I heard, server-fields don't take locks.

-- Mike

On 18 Dec 2012, at 13:33 , Steve Carton <[email protected]> wrote:

> I have a query that works through many documents looking for certain 
> elements/values (basically, cross references to other documents). It first 
> creates a new document for logging results. For each cross-reference found, 
> the query updates the log document by adding a new element as a child. It 
> also increments a counter in a server field. The query can run for a while - 
> there is a lot of content to go through, and it is a web application, so I'd 
> like to let the user know how the query is coming along.  So a separate query 
> is initiated as an Ajax request that should return the contents of the 
> server-field. Some javscript on the browser uses the response from that 
> second query to update a progress bar in the browser.
> 
> The problem is, the second query (the Ajax request for the contents of the 
> server field) won't start until the first query (the main one) is finished. 
> I've fooled with any number of techniques, including wrapping the inner 
> portions of the first query inside xdmp:eval wrappers to isolate the update 
> transactions and also spawning the query. Neither works (well, not quite 
> accurate - the spawn allows the second ajax query to run, but it doesn't 
> access the server-field, under spawn, the query seems to have its own server 
> fields?).
> 
> Any suggestions? What am I missing here.
> 
> -- 
> Steve
> _______________________________________________
> General mailing list
> [email protected]
> http://developer.marklogic.com/mailman/listinfo/general

_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general

Reply via email to