Re: RE : [mdr-dev] JdbcStorage update

Hi Olivier,

I remember you suggested this in the past but I still haven't made any 
progress on this front.

I think to do it properly requires the upper levels of MDR to also 
participate in the distributed transaction, because they also maintain 
transactional state outside of the persistence layer.

A more limited solution would be to require MDR to act as the 
distributed transaction coordinator.  In other words, requesting a 
commit or rollback from MDR would initiate the end of distributed 
transaction, which to MDR would look like a non-distributed transaction. 
  If we do it this way, then we can do it just at the persistence layer. 
  Would this work for you?

I haven't done any rigorous scalability tests.  Maybe we can collaborate 
on that as part of evaluating whether HSQLDB is good enough to serve as 
the official replacement for btrees.  Have you downloaded and built the 
code?  It's pretty easy to experiment if you confine yourself to the 
peristence layer; above that the meta-madness makes my brain hurt.

JVS

Olivier RICHAUD wrote:
> 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.