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

My opinion is that the easiest way for people developping application which
integrates various transactional is to join a global transaction. With
application servers and EJB, this is easy if the transaction is container
managed. I mean, the transaction is started by the container before the
method of the bean, and unless setRollbackOnly is called, the container
commit resources upon completion. This not only works for entity beans but
for other systems too : for example, we let entity beans aside because they
didn't fit our needs and replaced them with hibernate's persistent object.
Because Hibernate seamlessly integrates with application containers.

Concerning DR, and as long as I have understood the way it works, the
MDRManager is sort of transaction and persistence manager (Martin correct
please if i'm wrong). It handles concurrency with internal mutex.
Transaction are demarcated and the repository locked either in read only
mode, or exclusively in read/write mode. Hopefully, the application we are
building is essentially oriented towards consulting data and few
modificiation occurs. 

Another approach might be, but I haven't enough experience to talk a lot
about this, to rely on a database and use JDBC. Maybe this could help
integrate a transactional system.

Concerning Farago, relying on a transaction manager managed by an
application server would help users a lot. Again, the transaction
demarcation would be easy to understand and users wouldn't have to get rid
of a new transactional model. Take our application :
- an XML database which servces as a cache : it stores XMI documents
contained datasets produced by MDR and we run Xpath queries on it (why :
because MDR/JMI doesn't support powerful query language and Xpath is easy
and powerful)
- MDR itself
- a RDMBS for some other persistent data (user accounts, system data, ...)
As of today, none except the RDBMS can join a global transaction managed by
the container. We had to develop our tiny manager wich commits this 3
components in the right order. 

Regards.

Olivier.

-----Message d'origine-----
De : John V. Sichi [mailto:[email protected]] 
Envoyé : mercredi 28 janvier 2004 20:41
À : [email protected]
Objet : Re: [mdr-dev] RE : [mdr-dev] RE : [mdr-dev] RE : [mdr-dev] RE :
[FwdT: Re: [mdr-dev] JDBC persistence]


I'm going to be facing a similar problem soon, since in the Farrago DBMS 
project, MDR manages the metadata and a separate component manages 
relational data storage.  The reason I developed the JDBC storage layer 
is so that I can unify the two.  Immutable boot metadata about system 
tables will be stored in an MDR btree file; user data and metadata about 
user tables will be stored in relational tables.  In order to be able to 
mix DDL and DML in one transaction, I'll need to make the MDR 
transaction boundaries match the Farrago transaction boundaries.  I can 
solve the problem since I have top-level control, but it would be 
simpler if the components could participate in a larger transactional 
context as you describe.

JVS

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