Hello Christian,
thank you for your very detailed answer!
The twitter use case that you have mentioned as an example for concurrent updates is quite impressive.
From the perspecitive of J2EE one might ask for features like rollback or even 2 phase commit protocol.
But even the JBoss team had issues with the two phase commit when they developed their HornetQ messaging server [2]. I was astonished to see them in JBoss 6 release.
So it seems to be a wise decision to focus on the specific strength of an XML Database. And for our special use case the features mentioned in [1] are sufficient.
With best regards,
Andreas
[1] http://docs.basex.org/wiki/Transaction_Management#Update_Transactions
[2] http://www.jboss.org/hornetq
Am 14.02.2012 23:49, schrieb Christian Grün:
Dear Andreas,
thanks for your mail. Some answers (even if they may have been addressed to Godmar):
- Which of the BaseX interfaces do you use: XQJ or just the plain
ClientSession's?
In general, the plain client sessions will give you better performance, as they are very light-weight and comply better with the internal BaseX representation.
- Have you found an example to use XQJ for a remote BaseX - Database?
Currently, XQJ does only work with local database instances. This may change soon, as Charles Foster will soon offer a 100% compliant and client-/server-based driver for his XQJ implementation for BaseX (see xqj.net for more)!
- Have you found some documentation about the Java-client and
transactional support (for example to use BaseX even for a 'logging table')?
The BaseX documentation includes some basic information on transactions in BaseX [1]. Feel free to ask for more details.
- Are there substantial benefits of the Java-client versus the rest
client for such an application?
Again it's mainly about performance: the REST API is a little bit slower due to the HTTP communication overhead and its statelessness (each time, a new session has to be created, the addressed database has to be opened, etc). Depending on the way your queries look like, this may be more or less relevant: if you need to run hundreds or thousands of queries each minute, the overhead could impose a limit at some point; if you have a few number of queries that take considerable time, the overhead should hardly be noticeable.
- Have you already some experiences with the Java-client and BaseX under
high concurrent load?
To give an example: In one use cases, BaseX stores converts new JSON Twitter data to XML and stores it in a database appr. 300 times per second. Each hour, a new database is created; a single instance takes 4 GB in average (depending on the time of the day).
Feedback from everyone else is welcome; feel free to browse the mailing list archive [2] to find other usage scenarios.
Christian
[1]http://docs.basex.org/wiki/Transaction_Management [2]http://basex.org/service/mailinglist-search/