AW: [Objectbridge-developers] OJB Dependent Collections Update Be haviour

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

Hi Sasha,

> -----Urspr=FCngliche Nachricht-----
> Von: Sasha Haghani [mailto:sha...@br...]
> Gesendet: Dienstag, 29. Mai 2001 21:27
> An: 'Mahler Thomas'; 'obj...@li...'
> Betreff: RE: [Objectbridge-developers] OJB Dependent=20
> Collections Update
> Be haviour
>=20
>=20
> Hi Thomas (and friends),
>=20
> Thanks for the prompt response to my questions, but I've=20
> still got a few
> unresolved questions, so here they are...
>=20
> 1. Just for the sake of clarity, how would ODMG handle the use case I
> described in my last message?, namely:
>=20
> -> Call database.store() on A (ID:5) with collection of=20
> dependent B objects
> (IDs: 6, 7, 8, 9, 10)
> -> Subsequent database.store() call on A (ID:5) with Bs (IDs:=20
> 8, 9, 10, 11,
> 12).
>=20

The ODMG implementation sets the flags auto.update, auto.delete to =
false.
Thus a store on A does NOT automatically store the B objects!

BUT: if you add a B object to an ODMG collection A, it is automatically
registered to the current transaction. The transaction tracks all =
changes of
objects (newly created objects made persistent, modification of "old"
objects, deletion of "old" objects). On commit it will thus save all B
objects added to the collection.

To get an impression of this mechanism have a look at the method
ojb.server.collections.add(Object)
	public void add(int index, Object element)
	{
		TransactionImpl tx =3D (TransactionImpl)
OJB.getInstance().currentTransaction();
		tx.register(this);
		this.size++;
		DListEntry entry =3D new DListEntry(this, element);
		elements.add(index, entry);
		// changing the position markers of entries:
		int offset =3D 0;
		try
		{
			offset =3D ((DListEntry) elements.get(index -
1)).getPosition();
		}
		catch (Exception ignored) {}
		for (int i =3D offset; i < elements.size(); i++)
		{
			entry =3D (DListEntry) elements.get(i);
			entry.setPosition(i);
		}
	}

> 2. In your last message, you said the following regarding=20
> recursive handling
> of dependent objects by ODMG (Question #3):
>=20
> ---- Thomas Mahler wrote:
> > As mentioned above the registration of objects to transactions is
> recursive.
> > The store operations are not recursive (i.e. the=20
> auto.update, auto.delete
> > flags are set to false). But as everything is registered=20
> recursively the
> > ODMG implementation can still update all dependent objects.
> ----
>=20
> I didn't understand this.  Were you referring to the=20
> PersistenceBroker or
> the ODMG interface when you said "The store operations are=20
> not recursive"?
> Does this mean that when I have object A depending on Bs=20
> which depend on Cs,
> calling the ODMG Database's makePersistent(A) method won't properly
> insert/update the entire object graph?  Or did I misunderstand you?
>=20

OK I have make my point clearer. The ODMG implementation uses the
PersistenBroker.store() method. Thus it depends on you setting in the =
XML
repository whether you have cascading updates/deletes or not.
To avoid unnessary updates for dependent objects that have not been
modified, you can set auto.update, auto.delete to false. Then the
Transaction commit stores a A without the dependend B's and only those =
B's
that have been detected.=20

> 3. By Persistent Collections I'm assuming you were refering to the
> ojb.server.collections package which contains the ODMG collection
> implementations.  I had a look at all the classes but none of them
> implement/override any remove() methods so I don't see how=20
> the collections
> use the transaction manager to mark entries as deleted.  The=20
> persistent
> collections extend various Abstract Java collections in java.util
> (AbstractList, AbstractMap, etc.), but don't seem to override=20
> the remove
> methods.  Do the inherited remove() methods still work=20
> correctly in the
> subclasses?
>=20

You are absolutely right, remove() has not yet been implemented. So if =
you
use the ODMG collections with your A B example your B entries won't get
deleted right now!

> You mentioned that this wasn't fully implemented yet -- what=20
> is the current
> fuctionality and limitations of these collections?  When do you think
> they'll be completed?

I meant exactly the above mentioned remove() methods. It's not =
difficult to
implemnt those methods, so I can include them in the next release (say =
in 1
or 2 weeks)


>=20
> Does this also mean that in order to make use of ODMG's=20
> dependent object
> tracking facility (using the stateful transaction manager) that our
> persistent objects *must* use the persistent ODMG collections=20
> for dependent
> objects/relationships?  Or can we still use regular Java collections?
>=20

The ODMG specification requires an ODMG Vendor to implement certain
persistent collection Interfaces (DList, DBag, DSet ...).=20
But of course you can use arbitrary collections as provided by the OJB
PersistenceBroker.
BUT you are responsible for registering newly added objects and to mark
removed Objects as deleted.
This can be done by reimplemnting stuff from the ODMG collections in =
your
own collections.

> 4. Now that I understand the architecture of OJB, I see what=20
> functionality
> each is meant to provide.  Will JDO be built on top of ODMG,=20
> or directly on
> top of the Broker?=20

I think the best thing to do would be to build a OTM (ObjectTransaction
Manager) on Top of the broker and then only have very thin layers for =
the
ODMG and the JDO implementation.
This would of course require a complete refactoring of the ODMG =
package...


 I think that the next tutorial (#3)=20
> should definately
> address the handling of relationships and dependent objects. =20
> That is the
> bulk of the functionality and complexity which a tool like=20
> OJB addresses
> (along with inheritence and polymorphism).
>=20

Agreed!

(SO much work so little time)

Thomas

> Thanks again.
>=20
> Sasha Haghani,
> Toronto, Canada.
>=20
> -----Original Message-----
> From: Mahler Thomas [mailto:tho...@it...]
> Sent: Tuesday, May 29, 2001 3:26 AM
> To: 'Sasha Haghani'; 'obj...@li...'
> Subject: AW: [Objectbridge-developers] OJB Dependent=20
> Collections Update
> Be haviour
>=20
>=20
> Hi Sasha, hi all,
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: Sasha Haghani [mailto:sha...@br...]
> > Gesendet: Dienstag, 29. Mai 2001 02:00
> > An: 'obj...@li...'
> > Betreff: [Objectbridge-developers] OJB Dependent Collections Update
> > Behaviour
> >=20
> >=20
> > Hi Thomas,
> >=20
> > In your last message on the subject of how OJB updates=20
> collections of
> > dependent objects, you said:
> >=20
> > -----
> > Inserting newly added objects in a Collection attribute
> > DOES work!
> >=20
> > If you call PersistenceBroker.store(), the=20
> PersistenceBroker does NOT
> > know that you have deleted items from a collection! It does=20
> > only see the
> > actual items in the collection! If you use the=20
> > PersistenceBroker API you
> > have to implement your own tracking mechanism that detects obsolete
> > objects and call .delete(obj) on you own. (You could add such=20
> > a thing in
> > your collections .remove(obj) method).
> >=20
> > The ODMG implementation provides an object transaction=20
> > manager that does
> > contain such a tracking.
> > -----
> >=20
> > I have a number of questions about this, so I'll list them=20
> > one at a time...
> >=20
> > 1. Can you describe how the following case would be handled:
> > -> Call broker.store() on A (ID:5) with collection of=20
> > dependent B objects
> > (IDs: 6, 7, 8, 9, 10)
> > -> Subsequent broker.store() call on A (ID:5) with Bs (IDs:=20
> > 8, 9, 10, 11,
> > 12).
> >=20
> > As I understand it, in the database we would end up with A=20
> > related to 7 Bs
> > (IDs: 6 through 12), with Bs 8 through 10 updated on the=20
> > second call to
> > store().  Is this correct?
> >=20
>=20
> Yes, exactly. Of course this result is at least misleading=20
> (if not an error)
> as your intention is to have items 6 and 7 deleted from the DB!
>=20
> > 2. Why is it that the ODMG provides this collection tracking=20
> > facility but
> > the Broker does not?  Isn't the ODMG interface built on top=20
> > of the Broker?
> > How would ODMG handle the above case?
> >=20
>=20
> The Broker is designed to be stateless service. If you ask to store =
an
> object it just does so but it has no means to check previous=20
> state of your
> object.
> The Broker has been designed as a service providing db access for =
more
> complete stateful and transactional persistence manager like the ODMG
> implementation or the (planed) JDO implementation.
> The ODMG implementation USES the Broker but is not limited to=20
> the brokers
> features.
> This is a typical layered architechture.
>=20
> The ODMG implementation has a transaction manager that=20
> explicitely registers
> objects to transactions. Objects are registered recursively=20
> with all there
> dependent objects getting also registered. On registration a=20
> clone of each
> object is generated that contains the initial state of the=20
> object. On a
> transaction rollback the initial state of all objects is=20
> reconstructed. On
> commit The TransactionManager checks the ModificationState of each
> registered object. If an already persistent object has been=20
> modified it asks
> the PersistenceBroker to perform an UPDATE (by using an=20
> ObjectModification).
> If an Object is marked for deletion, the Broker is asked to=20
> perfom a DELETE,
> etc. (see the classes in package ojb.server.states, applying a "cool"
> combination of state- and command pattern).
>=20
> > 3. Does ODMG recursively update/handle dependent objects=20
> > (i.e.: A depends on
> > B which depends on C)?
> >=20
>=20
> As mentioned above the registration of objects to=20
> transactions is recursive.
> The store operations are not recursive (i.e. the auto.update,=20
> auto.delete
> flags are set to false). But as everything is registered=20
> recursively the
> ODMG implementation can still update all dependent objects. The big
> difference: ODMG does only update if necessary, the Broker does =
always
> update even if no modifications occured in dependent objects.
>=20
> > 4. How does ODMG know/determine which dependent=20
> > references/collections to
> > update/delete if ODMG ignores the auto.delete and auto.update=20
> > settings (as
> > you had said in an earlier message)?
> >=20
>=20
> The persistent collection classes are responsible to register=20
> new added
> elements to the current transaction and to mark=20
> element-entries (not the
> element objects themselves !) for deletion if they are=20
> removed from the
> collection. (This is not yet implemented completely, but you=20
> may get an idea
> of the interaction of colletcions with the TransactionManager=20
> by having a
> look at the class ojb.server.collections.DListImpl)
>=20
>=20
>=20
> > 5. Is it possible, safe and recommended to mix-and-match the=20
> > use of the
> > Broker interface for delete operations (since it handles=20
> > cascaded deletes of
> > dependent objects) and ODMG for update and insert=20
> operations (since it
> > handles updates on collections of dependent objects)?  Is it=20
> > wise to event
> > attempt this approach?  Can you forsee any potential problems?
> >
>=20
> No, don't do this! The PersistenceBroker does not track object
> modifications, has no object transactions, no lock management=20
> etc. So you
> would really get trouble using a mixed approach.
> The is one exception from this rule: It is safe to use the
> PersistenceBrokers query facilities to lookup objects.=20
>=20
> =20
> > 6. Finally, I may be interested in implementing this=20
> > collection tracking
> > facility for the Broker, depending on how complex and=20
> > time-consuming such an
> > undertaking would be.  Could you describe requirements (i.e.:=20
> > bullet points)
> > of how and where (in the source code) such an improvement=20
> > would be made,
> > including how other features such as Transactions, Object Cache,
> > Descriptors, Recursive Dependencies, would be affected. =20
> > Would it possible
> > to port the ODMG functionality into the Broker?
>=20
> Of course it's possible to implement this (as the ODMG implementation
> shows).
> You basically have to re-write everything of the ODMG=20
> implementation apart
> from OQL and named roots:
> - a TransactionManager that provides objectlevel transactions
> - a StateHandler that handles transaction commit and rollback
> - a LockManager handling concurrent object requests of transactions
>=20
> The JDO implementation will also reuse a lot of code from the odmg
> implementation.
> So it may be a valid approach to factor out these "Object=20
> TransactionManager
> (OTM)" to avoid "copy and paste"-reuse.
>=20
> But personally I think it's not a good idea to incorparate=20
> hese features
> into the Broker, because the Broker services are on a lower=20
> level than the
> OTM services. (The Broker must know about JDBC and the O/R=20
> mapping. The OTM
> must know nothing about JDBC but needs a service to perform =
store(obj)
> operations. Thus I would always recomend a layered approach.)
>=20
> thanks for your stimulating questions!
>=20
> Thomas Mahler=20
> Essen, Germany
>=20
>=20
> >=20
> > That's it for now.  Thanks again.
> >=20
> > Sasha Haghani
> > Toronto, Canada.
> >=20
> >=20
> > _______________________________________________
> > Objectbridge-developers mailing list
> > Obj...@li...
> > http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> >=20
>=20