Hi
I see, that all queries are really living in its "within my connection"
world and other clients, incl. GUI do not reflect it.
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)
--
*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.comwrote:
> ..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
>
>