concurrency within xquery

On Tue, Jan 22, 2013 at 12:50 PM, Seenivasan Gunabalan <seenivasan.gunabalan at dedalus.eu> wrote: > Hi all, > Is there a way to control concurrency from inside xqueries? Though > its possible to achieve concurrency through REST (and RESTXQ?) interface, I > am looking for ways to declaratively ask an xquery to run subqueries in a > concurrent way. > > Thanks in advance > Seenivasan > > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk >

On 2013-01-25 at 22:44 Christian Grün <christian.gruen at gmail.com> wrote: > One idea was to introduce a new pragma for explicitly locking parts of the > code. This could look as follows: > > (# db:lock #) { file:write(......) }

Am 22.01.2013 um 12:50 schrieb Seenivasan Gunabalan <seenivasan.gunabalan at dedalus.eu>: > Hi all, > Is there a way to control concurrency from inside xqueries? Though its possible to achieve concurrency through REST (and RESTXQ?) interface, I am looking for ways to declaratively ask an xquery to run subqueries in a concurrent way. > > Thanks in advance > Seenivasan > _______________________________________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-konstanz.de > https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk

On 01/28/2013 04:54 PM, Jens Erat wrote: > Hi Seenivasan, > > what exactly do you want to do? What kind of subqueries are you thinking about? > > There are currently no plans to support concurrent subqueries of a query, so a single query (regard as sending one request to the database) is always one transaction. You can find more information on how we're locking in our [wiki]. > > [wiki]: http://docs.basex.org/wiki/Transaction_Management > > - - - > > On 2013-01-25 at 22:44 Christian Grün <christian.gruen at gmail.com> wrote: > >> One idea was to introduce a new pragma for explicitly locking parts of the >> code. This could look as follows: >> >> (# db:lock #) { file:write(......) } > If you're looking for methods to implement your own locking (eg. for controlling access to external resources using our modules for files or HTTP access), this would be totally fine for you; but my main focus currently is at optimizing database locking (which is my thesis), so don't expect it to happen too soon (but it could happen earlier if somebody needs it). > > Kind regards from Lake Contance, Germany, > Jens >

> Hello Jens, > what we wanted to do is writing a testing client for our service framework > and we wanted to do it with BaseX as the testing client. An Xquery reading > the testcase (in XML) and using http-client for the request plus XSD/XSLT > and Xquery itself for doing the assertions on the outcome of the request. > This works pretty fine until it comes to "stress testing". We'd like to be > able to fire multiple simultaneous requests (let's say concurrently by > using threads). But there doesn't seem to be a way of expressing this in > XQuery. > Actually I've come accross several articles stating that the functional > programming model of Xquery should ease a parallel implementation and for > example you could consider flowr to be a parallel programming construct. > This makes pretty much sense to me and it would imply that we'd get the > parallel behaviour out of the box. > Consider also that we are not doing any DB access since the overall > testcase description XML is passed to the XQuery as a parameter and a > possible sotrage of the result would happen only at the very end of the > execution after re-joining everything into the single main thread. > Nevertheless it doesn't look like BaseX is taking advantage of parallel > execution under the hood. So I was wondering whether there is another way > of getting this "parallel or concurrent" behaviour of flowr. > Hope I could express our thoughts and I'm looking forward to listen to > your opinions on this matter. > Greetings, > M. > > > On 01/28/2013 04:54 PM, Jens Erat wrote: > >> Hi Seenivasan, >> >> what exactly do you want to do? What kind of subqueries are you thinking >> about? >> >> There are currently no plans to support concurrent subqueries of a query, >> so a single query (regard as sending one request to the database) is always >> one transaction. You can find more information on how we're locking in our >> [wiki]. >> >> [wiki]: http://docs.basex.org/wiki/**Transaction_Management<http://docs.basex.org/wiki/Transaction_Management> >> >> - - - >> >> On 2013-01-25 at 22:44 Christian Grün <christian.gruen at gmail.com> wrote: >> >> One idea was to introduce a new pragma for explicitly locking parts of >>> the >>> code. This could look as follows: >>> >>> (# db:lock #) { file:write(......) } >>> >> If you're looking for methods to implement your own locking (eg. for >> controlling access to external resources using our modules for files or >> HTTP access), this would be totally fine for you; but my main focus >> currently is at optimizing database locking (which is my thesis), so don't >> expect it to happen too soon (but it could happen earlier if somebody needs >> it). >> >> Kind regards from Lake Contance, Germany, >> Jens >> >> > ______________________________**_________________ > BaseX-Talk mailing list > BaseX-Talk at mailman.uni-**konstanz.de <BaseX-Talk at mailman.uni-konstanz.de> > https://mailman.uni-konstanz.**de/mailman/listinfo/basex-talk<https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk> >