objectbridge-developers Mailing List for ObJectRelationalBridge (Page 56)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> -----Urspr=FCngliche Nachricht-----
> Von: obj...@li...
> [mailto:obj...@li...]Im Auftrag
> von Dixon-Peugh, David
> Gesendet: Dienstag, 23. Januar 2001 22:30
> An: 'Thomas Mahler'
> Cc: 'objectbridge'
> Betreff: RE: [Objectbridge-developers] OJB Homepage, OQL
>
>
> I'm worried about code duplication then.
>
> Basically, so far Transaction implementation has been done completely
> from the ODMG side of things.  It seems like we need to move the
> implementation
> of the transactions to the Broker side of things.

I don't understand your argument.
Say we type A mapped to db oracle
and type B mapped to db mysql

then we could have the following ODMG session:

Implementation odmg =3D OJB.getInstance();
Database db =3D odmg.newDatabase();
db.open(databaseName, Database.OPEN_READ_WRITE);

Transaction tx =3D odmg.newTransaction();
tx.begin();

// 1. get OID's
A a =3D new A();
a.setId(89);
B b =3D new B();
b.setId(103);

String oid-a =3D odmg.getObjectId(a);
String oid-b =3D odmg.getObjectId(b);

// 2. lookup objects by OID
a =3D (A) db.lookup(oid-a);
b =3D (B) db.lookup(oid-b);

// 3. modify objects
a.setAttributeX("newValue"); // implicit call to markModified() !
b.setAttributeY("newValue"); // implicit call to markModified() !

// 4. commit
try
{
	tx.commit();
}
catch (Throwable t)
{
	tx.abort();
}

internally the commit results in a call to the transactions
ObjectStateTable::commit().

public void commit()
{
        try
        {
                broker.beginTransaction(); // broker is a private attribu=
te
                                           // of type PersistenceBroker
                Iterator i =3D table.values().iterator();
                while (i.hasNext())
                {
                        ObjectModification mod =3D (ObjectModification)
i.next();
                        mod.getModificationState().commit(mod);
                }
                broker.commitTransaction();
        }
        catch (Throwable t)
        {
                broker.abortTransaction();

                // the ODMG tx must abort too, when updating one of the
                // underlying rdbms failed:
                this.rollback();
        }
}

The PB opens transaction for for the databases oracle and mysql and is
sequentially called to store the modified objects a and b.
say writing a to oracle succeeds. But writing of b to mysql fails.
The Persistencebroker does not need any knowledge about the stored object=
s
or the sequence in which they had been updated. It simply has to rollback
the transactions against oracle and mysql and then to throw an Exception.
The database maintain a transaction log and know which operations have to
been rolled back.
There will be no code doubling and all knowledge about object modificatio=
ns
will stay in the ODMG part (namely the transactions ObjectStateTable.

>
> Once its on the broker side, then we can write the ODMG side as just a
> simple wrapper.
>
> BUT- The broker will need to have both explicit and implicit transactio=
ns
> if the ODMG stuff is going to be a wrapper.
>
> It almost makes sense to just go ahead and keep the ODMG
> transactions where
> it is as the explicit transaction.  And have the broker use it in build=
ing
> an implicit one.
>
> David.
>
>
> -----Original Message-----
> From: obj...@li...
> [mailto:obj...@li...]On Behalf O=
f
> Thomas Mahler
> Sent: Tuesday, January 23, 2001 4:14 PM
> To: Dixon-Peugh, David
> Cc: 'objectbridge'
> Subject: Re: [Objectbridge-developers] OJB Homepage, OQL
>
>
> "Dixon-Peugh, David" wrote:
> >
> > Right-o,
> >
> > I'll look into number 2 then.
> >
> > Of course your example brings in an interesting point.  Right now all
> > the transactions are handled in the "ojb.server" section.  But the
> > broker is responsible for storing the data.
> >
> > This means the broker will need to be aware of the Transaction which
> > may mix the broker/server code together.
>
> As I see it, there will be no mixing, we just have transaction on
> distinct layers:
> the ODMG server manages the transactions of all its clients. On
> committing these transactions it opens a PersistenceBroker transaction
> and now the PB has to manage the transaction against all the backend
> RDBMS.
> If something goes wrong during the PB commit, all RDBMS operations are
> rolled back and the PB transaction fails, which causes the ODMG
> transaction to fail also.
> As I see it the ODMG server depends on the PB transaction. What the PB
> has to do internally to manage all the JDBC transactions is of no
> interest to the ODMG layer. The only thing important is: does the PB
> compund transaction succeed or not? (the my commit() method below ).
> But the PB transaction do not in any way depend on the ODMG
> transactions.
>
> SO we have three layers of transactions:
> 1. JDBC transaction against the backend RDBMS
> 2. the compound PersistenceBroker transaction, coordinating all tx from
> 1)
> 3. the ODMG transactions. they need a PB transaction on commiting
>
> >
> > But, anyways, here is what I'm thinking now.
> >
> > The first thing the broker does, is to check whether a transaction is
> > open or not.
> >         If a transaction is open, then the operations that the broker
> > performs
> >                 fall under the current open transaction.
> >         If a transaction is not open, then the broker does its operat=
ion
> > under
> >                 an implicit transaction.
> >
> > This should be close to what CMT does in EJB, and certainly makes the
> > transactions
> > easier to implement.
> >
> > David
> >
> >
> >
> > -----Original Message-----
> > From: obj...@li...
> > [mailto:obj...@li...]On Behalf=
 Of
> > Thomas Mahler
> > Sent: Tuesday, January 23, 2001 1:49 PM
> > To: 'objectbridge'
> > Subject: Re: [Objectbridge-developers] OJB Homepage, OQL
> >
> > "Dixon-Peugh, David" wrote:
> > >
> > > Except of course, that QBE by itself (without extensions),
> > > is capable of everything that SQL does.  (They are both
> > > languages for Relational Algebra after all.)
> > >
> > > On another topic. . .
> > >
> > > I'm thinking about finishing up the Transaction support soon,
> > > however I've got some questions about how we want to implement
> > > it.  Perhaps you two could shed some light on what we should do.
> > >
> > > Basically, the issue is that if you use the raw JDBC driver, you
> > > cannot guarantee that two different connections will either both
> > > commit, or both abort.
> > >
> > > There are three ways around this that I can see:
> > >         1.  Ignore it.
> > >         2.  Force all JDBC connections to be the type that can
> > >                 participate in a distributed transaction.
> > >         3.  Have OJB maintain its own Transaction log which can
> > >                 be used to issue compensating transactions,
> or complete
> > >                 transactions when starting up again.
> > >
> > > One is the easiest to do, but you don't have real transactional
> integrity
> > > accross the database.
> > >
> > > Two will work, and it wouldn't be too hard to implement, but it lim=
its
> > > which JDBC drivers can be used.  (I don't think Postgres or some of
> > > the other free databases have a distributed capable JDBC driver.)
> > >
> > > Three will also work, but it is obviously more work, and also leave=
s
> open
> > > issues about ObJectBridge interacting with other more traditional
> > software.
> > > (The redo/undo of the log could overwrite something from the
> other App,
> as
> > > we don't have exclusive control over it.)
> > >
> >
> > Interesting point!
> > The PersistenceBroker (PB) is able to handle classes mapped to differ=
ent
> > RDBMS. As of today there is no handling of such "inherently distribut=
ed"
> > in PB.
> > Even worse: the store() or delete() method don't declare exceptions t=
o
> > allow detection of failed DB transactions. I introduced
> > beginTransaction(), commitTransaction() and commitTransaction() in th=
e
> > PB interface, but they do nothing yet.
> >
> > 1. sounds good :-)
> > The question is: do we really have to support the feature of persiste=
nce
> > against distributed RDBMS?
> > It would be quite easy to change the repository.dtd to disallow
> > JDBCConnectionDescriptors on a per class basis but to enforce usage o=
f a
> > one-for-all JDBC-connection.
> > This 30-second hack would finish the discussion for some time... (at
> > least until somebody asks "why can't I store my objects in different
> > databases?" )
> >
> > 2. this is my favourite solution. It would take some burden from our
> > shoulders through relying on the capabilities of the JDBC drivers and=
 on
> > the JTA standard.
> > Take for example the SOAP developers: they don't deal with security
> > issues at all in the 1.1 spec, but simply tell you to take care for t=
he
> > security of your transportlayer on your own.
> > I think this is a completely legitimate approach.
> > As a small team we have to concentrate our forces on the core things =
we
> > adress. And that is O/R mapping and not tx coordination between RDBMS.
> > So going this way we could offer: you can use PB to store Objects in
> > different database when the DB Vendors provide capable drivers. If th=
e
> > drivers don't support distributed tx you have no proper tx support.
> > Sorry, but it's not our fault...
> >
> > 3. We will definitely need a Transaction log in the ODMG server
> > (something like the ojb.server.ObjectStateTable) which tracks the
> > modification state of each object touched by a transaction. But I don=
't
> > like the idea of keeping a log of the SQL operations as well. (why sh=
all
> > WE do THEIR job ???)
> >
> > Here is the design I have in mind:
> >
> > a Transaction aware version of the ObjectStateTable::commit() method
> > could look like this:
> >
> > /** perform commit on all tx-states */
> > public void commit()
> > {
> >         try
> >         {
> >                 broker.beginTransaction(); // broker is a private
> attribute
> >                                            // of type PersistenceBrok=
er
> >                 Iterator i =3D table.values().iterator();
> >                 while (i.hasNext())
> >                 {
> >                         ObjectModification mod =3D (ObjectModificatio=
n)
> > i.next();
> >                         mod.getModificationState().commit(mod);
> >                 }
> >                 broker.commitTransaction();
> >         }
> >         catch (Throwable t)
> >         {
> >                 // let broker rollback all performed operations
> >                 // this relies only the brokers capability
> >                 // to properly handle distributed tx against
> >                 // multiple RDBMS:
> >                 broker.abortTransaction();
> >
> >                 // the ODMG tx must abort too, when updating one of t=
he
> >                 // underlying rdbms failed:
> >                 this.rollback();
> >         }
> > }
> >
> > So as far as I see it, from an ojb.server point of view you can ignor=
e
> > the underlying RDBMS completely by using the PersistenceBroker as a
> > blackbox which is responsible for proper 2 phase commits against all
> > RDBMS.
> >
> > what do you think ?
> >
> > regards,
> > the other Thomas :-)
> >
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/lists/listinfo/objectbridge-developers

2000	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (14)	Dec (20)
2001	Jan (33)	Feb (8)	Mar (3)	Apr (1)	May (18)	Jun (6)	Jul (15)	Aug (71)	Sep (29)	Oct (43)	Nov (77)	Dec (54)
2002	Jan (54)	Feb (147)	Mar (144)	Apr (163)	May (307)	Jun (240)	Jul	Aug	Sep (1)	Oct	Nov	Dec

objectbridge-developers Mailing List for ObJectRelationalBridge (Page 56)

objectbridge-developers — public list for developer issues