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
Hi Seenivasan,
by chance, we’ve recently thought about such a feature, but we’re not sure yet if it can be realized without undesired side-effects. One idea was to introduce a new pragma for explicitly locking parts of the code. This could look as follows:
(# db:lock #) { file:write(......) }
Jens may give you some more information soon, Christian ___________________________
On Tue, Jan 22, 2013 at 12:50 PM, Seenivasan Gunabalan seenivasan.gunabalan@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@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
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@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].
On 2013-01-25 at 22:44 Christian Grün christian.gruen@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
Hi Marco,
As far as my exploration, current BaseX's XQuery processor implementation is based on single thread processing. And yes, you are right that from programming model point of view, it is (should be) possible to create parallel implementation of XQuery processor, however it is currently not yet available in BaseX. I am still working on that direction, but for now, I cannot give you possible time when will it available.
Regards, -andria
On Tue, Jan 29, 2013 at 10:24 AM, Marco Lettere marco.lettere@dedalus.euwrote:
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].
On 2013-01-25 at 22:44 Christian Grün christian.gruen@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@mailman.uni-**konstanz.de BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.**de/mailman/listinfo/basex-talkhttps://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
basex-talk@mailman.uni-konstanz.de
-
Andria Arisal -
Christian Grün -
Jens Erat -
Marco Lettere -
Seenivasan Gunabalan