Thanks for the suggestion, but I don't think that'd work in this case as the unlock method seems to want to unlock *all* locked nodes. But as I said below, the event bundle isn't my bag, so I might be wrong about this.
Justin On Mon, Mar 21, 2011 at 10:12 AM, Ruben Reusser <[email protected]> wrote: > you might want to fix the sql2 query by setting a max result count - usually > speeds up sql queries by a large magnitude. > > Ruben > > On 3/21/2011 7:07 AM, Justin Edelson wrote: >> >> On Sat, Mar 19, 2011 at 11:23 AM, Carsten Ziegeler<[email protected]> >> wrote: >>> >>> Justin Edelson wrote >>>> >>>> While looking at the threads web console plugin (my best friend as of >>>> late), I noticed that the >>>> org.apache.sling.event.impl.jobs.jcr.LockManager component was taking >>>> a long time to activate. >>>> >>>> Looking at the code, I see that a JCR SQL2 query is used on line 314: >>>> final Query q = qm.createQuery("select * from [nt:base] >>>> where [" + JCRHelper.NODE_PROPERTY_LOCK_OWNER + "] = '" + searchString >>>> + "'", >>>> Query.JCR_SQL2); >>>> >>>> Is there any reason why this needs to be a SQL2 query? It doesn't >>>> appear that way. >>>> >>>> This isn't a part of the codebase which I've done a lot of work in, so >>>> I didn't want to change it to XPath without getting some feedback. >>>> >>> No, there is no real reason behind it - except that I wanted to avoid >>> deprecated features - but if the new stuff is slow compared to the >>> deprecated versions (which is really odd) than we should simpyl switch >>> back. >> >> OK. I'll apply the patch attached to SLING-2080. >> >> I saw this make orders of magnitude difference - the SQL2 query took >> minutes to run whereas the SQL query took 8 ms. >> >> Justin >> >>> Regards >>> Carsten >>> -- >>> Carsten Ziegeler >>> [email protected] >>> >
