RE : [mdr-dev] JdbcStorage update

"Olivier RICHAUD" <[email protected]> Sat, 27 Nov 2004 22:30:38 +0100
Newsgroups gmane.comp.java.netbeans.modules.mdr.devel
Message-ID <[email protected]>
John,

Your JBDC approach is very interresting and I have a question :

Did you consider to use JTA transaction to commit and rollack changes? I =
use
MDR in conjunction with relational database (mySQL or Oracle) and I have
been forced to develop sort of heterogenous transaction manager to =
ensure
atomicity. Using the same JDBC connection to commit both MDR and my JDBC
connection would solve all my problems. Another point would be to =
integrate
it with EJB container managed transactions.

I'm also running into troubles with MDR own storage system. When adding =
and
removing huge amounts of data, the files grows. This is rather =
disturbing
because it slows down my application. Using JDBC may get rid of that
problem. But did you try to use your implementation with a big model and =
a
huge XMI data file? I can send these files if you want.


-----Message d'origine-----
De : John V. Sichi [mailto:[email protected]]=20
Envoy=E9 : samedi 27 novembre 2004 12:22
=C0 : [email protected]
Objet : [mdr-dev] JdbcStorage update


JdbcStorage has been broken for a while due to build changes and changes =

to the MDRCache class which JdbcStorage borrows from BTreeStorage.  I=20
just checked in fixes so it should build and run again.  I also fixed=20
some other bugs I found in my code.

I'm finding that JdbcStorage with the latest release of HSQLDB running=20
in-process appears to be even a little faster than BTree storage.  This=20
is just from casual observation with small data sets.  But it raises the =

question:  instead of continuing to put effort into the BTree library=20
(e.g. enhancing with java.nio), why not replace it with an embedded Java =

database instead?  HSQLDB uses java.nio already, and supports both=20
memory-based and disk-based tables.  Its license recently changed to=20
new-BSD (the old advertising clause was removed) which is compatible=20
with just about anything.  They claim performance has improved a lot,=20
and it has crash recovery.

Or if something more robust is required, there's Derby nee Cloudscape.=20
I haven't tried it yet.

JVS