Hi Jan,

all connected clients are working on the same databases, so they reflect each update (no reconnection is needed). In the moment the transactions are multiple reader and single writer, so each writing transaction is blocking all other transactions till it is finished. No updating conflicts can arise.

I hope this helps, kind regards, Andreas

Am 22.10.2010 11:47, schrieb Jan Vlčinský (CAD):

Hi I see, that all queries are really living in its "within my connection" world and other clients, incl. GUI do not reflect it.

Could someone explain, what exactly can be expected from that?

Will other clients see mu updates after they reconnect? Can there arise some conflict? Like two clients updating the same node at the same time.

These are quite important facts as it may affect way of deployment significantly (I am planning implementation, where we will handle traffic information with changes in minute by minute manner)

With best regards

Jan

-- 

*Ing. Jan Vlčinský* CAD programy Slunečnicová 338/3, 734 01 Karviná Ráj, Czech Republic tel: +420-597 602 024; mob: +420-608 979 040 skype: janvlcinsky; GoogleTalk: jan.vlcinsky@gmail.com mailto:jan.vlcinsky@gmail.com http://cz.linkedin.com/in/vlcinsky

On Fri, Oct 15, 2010 at 9:24 PM, Christian Grün <christian.gruen@gmail.com mailto:christian.gruen@gmail.com> wrote:

..thanks for your feedback. I have passed to pass this on to our
mailing list, as it might be of general interest.

> A bug report from me. I just decided to test that REST web
services work
> correctly. So I did the following:
> 1. Opened window client, executed simple xquery to find a
document by id:
> /tagname[@id='id_value']
> 2. Removed this document via browser:
>
http://localhost:8984/basex/jax-rx/collection?command=delete+document.xml
> 3. Repeated the same xquery execution in window client.
> 4. Got the following stack trace:
> [...]

Note that the REST/JaxRx implementation starts a server instance of
BaseX, which does not communicate with the GUI version of BaseX. As a
result, and for the sake of performance, the changes performed via
REST won't be reflected in the visual frontend. You shouldn't
encounter any problems if you stay in one world, i.e., if you do all
communication with REST, or the command-line client connecting to the
server instance.

> BTW, could you also say if your database was successfully used
in Production
> systems with heavy load?

We have lots of users who operate BaseX in read-only environments, and
we're continuously extending our support for scenarios that depend on
stable realtime updates. Indeed, BaseX is very performant when it
comes to updates – it's actually much faster than most competing
systems we have tested by now – which is due to the fact that we have
a very low updating overhead (no indexes are updated, no backups are
performed for rollbacks, etc). Instead, BaseX includes manual features
to rebuild your indexes and backup/restore the data. If you want to
perform some tests on your workloads, I recommend to work with the
latest version of BaseX (6.2.9), which included many fixes that have
optimized the stability of our update operations. Along with the next
official version, you'll get better documentation on the latest
features. Advanced, optional update/transaction features to further
minimize the danger of losing data are on our todo list.

Hope this helps,
Christian
___________________________

Christian Grün
University of Konstanz
Department of Computer & Information Science
D-78457 Konstanz, Germany
Tel: +49-7531-88-4449, Fax: +49-7531-88-3577
http://www.inf.uni-konstanz.de/~gruen
<http://www.inf.uni-konstanz.de/%7Egruen>

---

BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk