RE : [mdr-dev] RE : [mdr-dev] RE : [mdr-dev] RE : [FwdT: Re: [mdr-dev] JDBC persistence]

You're right but this is the case for all transactional tools. You need to
register step by step. 

Integrating MDR with Jboss has nothing to do with distributed transaction.
You need to use Jboss transaction coordinator, and in the case of several
Jboss instanced, it will deal with distributed transactions. Anyway, this
would imply that MDR register each transactional object with the current
transaction and relies on the transaction manager. 

[Slight out of topic]
Of course, this is far beyond a JDBC persitency layer, but this should be
the right direction for MDR, especially in standalone mode. And this is not
only address Jboss, but any application server. This is the problem of this
kind of tool : none integrates a standard transactional mechanism and all
develops their transactional mechanism. For example, this is the case in our
tool : this would have been so easy if the XML database, the persistent
objects and the MDR had a way to join the current transaction. 

Hope this helps.

Olivier.

-----Message d'origine-----
De : John V. Sichi [mailto:[email protected]] 
Envoyé : dimanche 25 janvier 2004 23:56
À : [email protected]
Objet : Re: [mdr-dev] RE : [mdr-dev] RE : [mdr-dev] RE : [Fwd: Re: [mdr-dev]
JDBC persistence]


Olivier RICHAUD wrote:
> I think it could make sense. Let suppose we modify MDR's state because 
> we have create a new objet. This may correspond to an application 
> state which must persistent. Both states must committed together : the 
> transaction is a multi-database transaction. In this case, Jboss 
> transaction manager will ensure atomicity and soundness.

Right.  This is possible, but it requires more than just a JDBC storage 
implementation, because MDR maintains additional transactional state 
outside of the storage subsystem.  So all levels of MDR would need to 
participate in the distributed transaction.

JVS