RE: [Objectbridge-developers] OJB Homepage, OQL

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