Re: [Objectbridge-developers] OJB Homepage, OQL

[Thomas M. <tho...@ho...>]

"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 :-)