Re: [basex-talk] Global locks

Hi Andy, > Is it required to specify all databases accessed within the manualock scope > or could it work just specifying specific databases as readonly? > And the execution would error if these were violated. Sounds good. I have opened a new issue [1]; we welcome further syntax proposals.

Re: [basex-talk] Global locks

I look forward to the longer term solution :) But in the meantime these pragmas, although not pretty, would allow solutions to specific multitasking performance issues to be explored where currently they can be difficult/impossible. I think there is a certain elegance in advisory nature of

Re: [basex-talk] Global locks

> Would this work where the database names are only known at run time? Right now, our locking is based on static code analysis; runtime information won’t be included. In the longer term, we would like to extend our compiler to perform multiple steps: 1. Static parsing 2. Static optimizations

Re: [basex-talk] Global locks

> On 13 Feb 2019, at 16:38, Christian Grün wrote: > Manual locks could either be assigned globally or > within a query: > > (# db:manuallock #) { >(# basex:write-lock BEP-Staging #) { > (# basex:read-lock BEP #) { >let $d:=db:open('BEP') >return

Re: [basex-talk] Global locks

e simple - but might be easier and more reliable than > trying to find more optimisations to the locking algorithm. > > Just thinking aloud… > > Kindest regards, James > > From: Christian Grün > Subject: Re: [basex-talk] Global locks > Date: 11 February 2019 a

Re: [basex-talk] Global locks

to address another. I’m sure this wouldn’t be simple - but might be easier and more reliable than trying to find more optimisations to the locking algorithm. Just thinking aloud… Kindest regards, James > From: Christian Grün > Subject: Re: [basex-talk] Global locks > Date: 11 Febr

Re: [basex-talk] Global locks

Hi Andy, The current behavior is correct indeed – but it might not be what one expects. Currently, we are… a) collecting all static database references in the query and b) assigning either read or write locks to these databases, depending if the overall query is updating or not. The reason is

Re: [basex-talk] Global locks

sorry typo there, should be: I expected *BEP *to appear only in the Read locking, as it does if I remove the db:create call On Fri, 8 Feb 2019 at 16:03, Andy Bunce wrote: > Using 9.1.2 > > let $d:=db:open(``[BEP]``) > return db:create(``[BEP-staging]``,$d,$d!base-uri(.)) > > The GUI query

Re: [basex-talk] Global locks

Using 9.1.2 let $d:=db:open(``[BEP]``) return db:create(``[BEP-staging]``,$d,$d!base-uri(.)) The GUI query info reports: - Read Locking: (none) - Write Locking: BEP,BEP-staging I expected BEP-staging to appear only in the Read locking, as it does if I remove the db:create call Is this correct?

Re: [basex-talk] Global locks

> The use of String Constructor does not avoid the global read lock Good to know, thanks. It now does [1], provided that the constructor consists of a single static strings. [1] http://files.basex.org/releases/latest/ > duration="PT0.007S" reads="(global)" >

Re: [basex-talk] Global locks

The use of String Constructor does not avoid the global read lock, but I can see with some changes and a suitable set of conventions this could be made to work. Cheers /Andy count( collection(``[BEP]``)) On 20 September 2017 at 23:28, Christian Grün wrote: > >

Re: [basex-talk] Global locks

> bxcode:inline-variables($xqcode-uri) as xs:string > @returns xquery code that is the source code from $xqcode-uri but with > inlining "constant" variables and operations applied > > This could be used as a preprocessor. > Is this something that could be created from the bits and pieces in the >

Re: [basex-talk] Global locks

Thanks for the explanation. Wanting to parameterise the input collections, in fairly simple ways, seems to me a natural and common requirement. but the consequence of a global read lock is all other tasks are unable to access any database. So great care required ;-) >Variables will only be

Re: [basex-talk] Global locks

Hi Andy, > Note @reads="BEP" > > Is this correct and/or of any consequence? This is correct: If the argument of fn:collection, fn:doc, etc. is directly supplied as string argument, it is possible to statically detect (at parse time) which database needs to be locked. Variables will only be

[basex-talk] Global locks

Running the following in the GUI (8.6.5) ``` let $db:="BEP" return count(collection($db)) ``` The info windows shows $db is inlined Compiling: - inline $db_0 - pre-evaluate collection("BEP") to document-node() sequence - pre-evaluate count((db:open-pre("BEP",0), ...)) to xs:integer - simplify