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