Changes done by one client reflected to others - how
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 http://cz.linkedin.com/in/vlcinsky On Fri, Oct 15, 2010 at 9:24 PM, Christian Grün <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
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
participants (2)
-
Andreas Weiler -
Jan Vlčinský (CAD)