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

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

Hi Sasha, hi all,

> -----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 collections of
> dependent objects, you said:
>=20
> -----
> Inserting newly added objects in a Collection attribute
> DOES work!
>=20
> If you call PersistenceBroker.store(), the 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

Yes, exactly. Of course this result is at least misleading (if not an =
error)
as your intention is to have items 6 and 7 deleted from the DB!

> 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

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 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 the =
brokers
features.
This is a typical layered architechture.

The ODMG implementation has a transaction manager that explicitely =
registers
objects to transactions. Objects are registered recursively with all =
there
dependent objects getting also registered. On registration a clone of =
each
object is generated that contains the initial state of the object. On a
transaction rollback the initial state of all objects is reconstructed. =
On
commit The TransactionManager checks the ModificationState of each
registered object. If an already persistent object has been modified it =
asks
the PersistenceBroker to perform an UPDATE (by using an =
ObjectModification).
If an Object is marked for deletion, the Broker is asked to perfom a =
DELETE,
etc. (see the classes in package ojb.server.states, applying a "cool"
combination of state- and command pattern).

> 3. Does ODMG recursively update/handle dependent objects=20
> (i.e.: A depends on
> B which depends on C)?
>=20

As mentioned above the registration of objects to transactions is =
recursive.
The store operations are not recursive (i.e. the auto.update, =
auto.delete
flags are set to false). But as everything is registered 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.

> 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

The persistent collection classes are responsible to register new added
elements to the current transaction and to mark element-entries (not =
the
element objects themselves !) for deletion if they are removed from the
collection. (This is not yet implemented completely, but you may get an =
idea
of the interaction of colletcions with the TransactionManager by having =
a
look at the class ojb.server.collections.DListImpl)



> 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 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?
>

No, don't do this! The PersistenceBroker does not track object
modifications, has no object transactions, no lock management 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
> 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?

Of course it's possible to implement this (as the ODMG implementation
shows).
You basically have to re-write everything of the ODMG 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

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 =
TransactionManager
(OTM)" to avoid "copy and paste"-reuse.

But personally I think it's not a good idea to incorparate hese =
features
into the Broker, because the Broker services are on a lower level than =
the
OTM services. (The Broker must know about JDBC and the O/R 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.)

thanks for your stimulating questions!

Thomas Mahler=20
Essen, Germany


>=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