WG: [Objectbridge-developers] Reader/Writer Locks and other such stuff

[<tho...@it...>]

-----Ursprüngliche Nachricht-----
Von: Dixon-Peugh, David [mailto:Dav...@tp...]
Gesendet am: Dienstag, 5. Dezember 2000 17:58
An: 'tho...@it...'
Betreff: RE: [Objectbridge-developers] Reader/Writer Locks and other
such stuff


> ----
> My thoughts are, that if we are storing several objects in the same
> database,
> we want the PersistenceBroker to write them all within the same
> Transaction.
>
> If we use PersistenceBroker as it is now, it will store each object
> independently.
> (Rolling back the database transaction becomes a problem.)

Oops! Thats's a problem that I did not care about before. Here my Idea:
we need control the transactional brace used by PersistenceBroker manually.
So we need new methods:
PersistenceBroker::beginTransaction()
PersistenceBroker::commitTransaction()
PersistenceBroker::abortTransaction()


And in ObjectStateTable we have to modify the method commit() as follows:
public void commit()
{

PeristenceBrokerFactory.createPersistenceBroker().beginTransaction();

	try {
		Iterator i = table.values().iterator();
		while (i.hasNext())
		{
			ObjectModification mod = (ObjectModification)
i.next();
			if (_debug) System.out.println("committing: " +
mod);
			mod.getModificationState().commit(mod);
		}

PeristenceBrokerFactory.createPersistenceBroker().commitTransaction();
	}
	catch (Exception ignored)
	{

PeristenceBrokerFactory.createPersistenceBroker().abortTransaction();
	}
}


So far so good.
But I see 2 more problems here:
1. By design the PersistenceBroker can store different classes in different
databases.
Hence the PersistenceBroker has to manage transactions against (potentially)
multiple RDBMS

-----

If the database driver supports JTS, it isn't a problem to coordinate
everything,
if it doesn't, then we have some interesting failure cases, but we should
come close.

-----

2. The sequence of object commits is an issue!
Imagine the creation of a new order object with dependend OrderPos Objects.
The depend objects might be at position 1, 3, 4, 5, 7 of the
ObjectStateTable.table and the Order Object might be at position 23.
If we sequentially commit the objects from the table, insertion of the
dependen objects will fail if there is referential integrity (RI) defined on
the DB. (you cannot insert a row referencing a row in a another table that
is not yet inserted)
For Delete it's just the other way round: you can delete the order only
after deletion of all dependent orderpos!

-----

I seem to remember somewhere that RI is not enforced until the Commit.  But,
I can't remember where I heard it from, or which database it involves, so
take that with a grain of salt.

-----

Maybe we can ignore this issue at the moment, because we can define our demo
database not to use RI. But as ObJectBridge aims at working with arbitrarily
defined RDMS, it's IMHO a thing that should be addressed.


best regards,


Thomas

-----

What I was thinking about, is using essentially different Object Brokers
depending
on the source.  So, all objects pulled from Sybase are handled by a Sybase
broker,
and all objects pulled from Oracle are handled by an Oracle broker.

It should also be possible to have a single object represented in both
Oracle and
Sybase, which I don't believe can happen at this moment.  (One of my jobs, I
had
to synchronize customer objects throughout an Enterprise, in many different
databases, so I suspect having one object in multiple databases is a real
concern.)

David.