Hi Mike,
Well, I'm puzzled by it too. The approach you describe below is exactly
what I am doing - the browser launches the long-running query as an
async ajax request and then polls using subsequent async requests. The
only ideas I've come up with so far are that maybe, since the
long-running query is updating, it is somehow blocking the subsequent
queries. Which is why I tried wrapping those portions in an eval. But it
doesn't seem to matter.
I don't think the longer query is blocking on the server fields, unless
maybe the query analyzer figures that out in advance (as it does for
updates). I also make async calls for other info and those are blocked too.
Steve
On 12/18/2012 4:53 PM, Michael Blakeley wrote:
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
--
/Steve/
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
