RE: [Objectbridge-developers] OJB Transactions

[Dixon-Peugh, D. <Dav...@tp...>]

I picked up a bit with the NamedRoots thing.  (Check for NULL, 
moved the txAbort and txCommit into doCommit, doAbort.  Moved
the DbImpl declaration to the head of the file, etc.)

I also created three classes:
	UpdateTransactionWrapper
	InsertTransactionWrapper
	DeleteTransactionWrapper

These all extend ObjectTransactionWrapper (with the Update specific
stuff moved to UTW)

These will be responsible for committing individual objects which
have been part of the transaction.

As for how to do this with the broker code, I'm not sure.

(I'm stuck at work for another 15 minutes, if I think of anything
I'll mail.)

David.


-----Original Message-----
From: obj...@li...
[mailto:obj...@li...]On Behalf Of
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 operation
> 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 limits
> > 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 leaves
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 different
> RDBMS. As of today there is no handling of such "inherently distributed"
> in PB.
> Even worse: the store() or delete() method don't declare exceptions to
> allow detection of failed DB transactions. I introduced
> beginTransaction(), commitTransaction() and commitTransaction() in the
> PB interface, but they do nothing yet.
> 
> 1. sounds good :-)
> The question is: do we really have to support the feature of persistence
> 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 of 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 the
> 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 the
> 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 shall
> 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 PersistenceBroker
>                 Iterator i = table.values().iterator();
>                 while (i.hasNext())
>                 {
>                         ObjectModification mod = (ObjectModification)
> 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 the
>                 // underlying rdbms failed:
>                 this.rollback();
>         }
> }
> 
> So as far as I see it, from an ojb.server point of view you can ignore
> 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