Hello,
I am having noticeable performance degradation for updating existing
database in this function with Basex 81. I can say this function never
finish with 81. But when I replace nodes call with file:append (writing
result to a file), I can see it is slowness.
But Basex_79 is much faster tha
Simon,
I am glad to report the concurrency bug in the user access code has
been fixed [1,2]. BaseX 8.1.1 may already be released this week. Of
course, please report back to me if you should encounter additional
bugs.
Thanks for testing,
Christian
[1]
https://github.com/BaseXdb/basex/commit/b5d1
That was fast :-) . Thank you very much. I will test it right away.
Regards
Simon
On Tue, Apr 14, 2015 at 3:28 PM, Christian Grün
wrote:
> Simon,
>
> I am glad to report the concurrency bug in the user access code has
> been fixed [1,2]. BaseX 8.1.1 may already be released this week. Of
> cour
I have minimized your example a bit (attached), and I agree it seems
to be the user iterator that causes surprises.
Looking at it..
Christian
On Tue, Apr 14, 2015 at 1:48 PM, Christian Grün
wrote:
> Hi Simon,
>
> Thanks for the updated code. It's still quite a lot code.. Is all of
> it require
Hi Simon,
Thanks for the updated code. It's still quite a lot code.. Is all of
it required to reproduce the bug? E.g., does the bug only occur with
the specified options etc? Could you possibly reduce it even more?
Idealle, we can later rewrite it to a JUnit test once the problem is
fixed (and we
Hello Christian,
I checked again my code, but I am quite sure that each LocalSession is
created and used by only one thread.
I attach the test application code.
Each LocalSession is used to execute several commands, but that shouldn't
be a problem, right ?
I also had a look in BaseX code, especi
6 matches
Mail list logo
