Gianugo Rabellino wrote:
Nice to see you here, John. :-)
I'm spying on you ;-)
Af fo transaction, sorry, let me rephrase it better, I didn't make myself clear: if you want ACID then you need transactions for operations that modify the database. But on a mostly-read database the transaction code might well be slow, since you are not doing many writes. So, even if JTA might impose a performance penalty, if the model is mostly read then it might be worth using that in the immediate future. Does this sound better?
The reads performance difference between a transacted store and an untransacted store
should be very small. You'd only notice the difference with very high conconcurrency and
very high query rates (typically many thousands per second). I think that you are assuming
that a transacted store means that reads have to be performed within a transaction. This is
not the case. LDAP servers typically transact updates and don't transact reads.
I don't know much about JTA... but I thought it was an interface for distributed transactions?
XA for Java?
Transactions are also a troublesome topic to discuss, as the term is overloaded with meaning.
For your server you need to think about transactions at three layers... internal, external, and
distributed.
BTW, John, do you know if Sleepycat made a final resolution about what will be the bdxml license? I.e.: will we be able to use bdbxml as a backend for Xindice like Mysql does with Berkeley DB? This is one of the paths I'm currently exploring, but I might well be wasting my time here if the license doesn't allow us to use it.
DB XML is released under the same license as Berkeley DB. Basically, if you're open
source then we're open source, if you're proprietary then you need to buy a license. We
have alpha code available if anyone wants to play :-)
John
