2 Liens interessant sur ces sujets
1) Transactions: HSQLDB does *not* support transaction isolation. All transactions run in read uncommitted ( dirty read mode). Transactions read dirty data ( uncommitted data) which is not what you want in case of update transactions/ lets say a banking application.
2) In-memory database: HSQLDB by default creates table in memory , so if you use CREATE TABLE the table is in memory. This means with large amounts of data there is high memory utilization and the application may be limited to the amount of memory available and may perform slow if table does not fit in memory.
http://www.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQDB talks about out of memory errors as a result. http://www.devx.com/IBMCloudscape/Article/21773 this article talks about how this could lead to scalability issues
3) Reliability:
But on the other hand, it seems like hsqldb is not failsafe as the log file is not flushed (synced) to the disk after a commit.
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=derby- [EMAIL PROTECTED]&msgNo=11 http://nagoya.apache.org/eyebrowse/ReadMsg?listName=derby- [EMAIL PROTECTED]&msgNo=13 gives a little more detail on the log flusher thread for hsqldb.
Je suis de plus en plus �tonn� du choix de ce moteur de base de donn�es. J'ai cherch� un lien qui en expliquait les motivations techniques. Depiuis que je regarde (un peu) hsqldb, je vois beaucoup des trucs n�gatifs.
Et quand je consulte les liens ci-dessus, �a fait carr�ment peur.
Quel est l'objectif initial d'int�gration d'une base de donn�es � OOo ?
-- Michel Pinquier Livre 'OpenOffice.org 1.1 efficace' - Editions Eyrolles
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
