RE : [mdr-dev] RE : [mdr-dev] JdbcStorage update

John,

For the scability test, I'm putting that on my so long todo list! I need
some
time to banch the JDBC layer.

Concerning MDR and transaction management, this is not at all suitable : =
MDR
is only a layer in my architecture and my application must retain =
control on
the global transaction : I'm committing many other things in my
transactions.

I think I'm going to thoroughly test your JDBC implementation.=20

Thanks for your reply.=20

Olivier.

-----Message d'origine-----
De : John V. Sichi [mailto:[email protected]]=20
Envoy=E9 : dimanche 28 novembre 2004 10:55
=C0 : [email protected]
Objet : Re: [mdr-dev] RE : [mdr-dev] JdbcStorage update


Hi Olivier,

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

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

A more limited solution would be to require MDR to act as the=20
distributed transaction coordinator.  In other words, requesting a=20
commit or rollback from MDR would initiate the end of distributed=20
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=20
the official replacement for btrees.  Have you downloaded and built the=20
code?  It's pretty easy to experiment if you confine yourself to the=20
peristence layer; above that the meta-madness makes my brain hurt.

JVS

Olivier RICHAUD wrote:
> John,
>=20
> Your JBDC approach is very interresting and I have a question :
>=20
> Did you consider to use JTA transaction to commit and rollack changes? =

> I use MDR in conjunction with relational database (mySQL or Oracle)=20
> and I have been forced to develop sort of heterogenous transaction=20
> manager to ensure atomicity. Using the same JDBC connection to commit=20
> both MDR and my JDBC connection would solve all my problems. Another=20
> point would be to integrate it with EJB container managed=20
> transactions.
>=20
> I'm also running into troubles with MDR own storage system. When=20
> adding and removing huge amounts of data, the files grows. This is=20
> rather disturbing because it slows down my application. Using JDBC may =

> get rid of that problem. But did you try to use your implementation=20
> with a big model and a huge XMI data file? I can send these files if=20
> you want.