AW: [Objectbridge-developers] ODMG or generic interface

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

Hi Lasse,

thanks for your interest!

> -----Urspr=FCngliche Nachricht-----
> Von: Lasse Lindg=E5rd [mailto:ll...@li...]
> Gesendet: Mittwoch, 22. August 2001 23:44
> An: obj...@li...
> Betreff: [Objectbridge-developers] ODMG or generic interface
>=20
>=20
> Hi,
>=20
> First: this project looks really cool!
> I downloaded it, ran the examples and read the tutorial. It is well
> written and I understood what was going on right away. Good job.
>=20
> Now I am considering trying objectbridge for a real sample.
>=20
> Could you explain to me - preferable in more than just one sentence -
> what the difference between the two interfaces is ?
>=20

The PersistenceBroker (PB) provides a minimal API for transparent
persistence:
- O/R mapping
- Retrieval of objects with a simple query interface from RDBMS
- storing (insert, update) of objects to RDBMS
- deleting of objects from RDBMS

This is all you need for simple applications as tutorial1.

The OJB ODMG implementation uses the PB as its persistence kernel. But =
it
provides much more functionality to the application developer. ODMG is =
a
full fledged API for Object Persistence, including:
- OQL Query interface
- real Object Transactions
- A Locking Mechanism for management of concurrent threads (apps) =
accessing
same objects
- predefined persistent capable Collections and Hashtables

I give some examples about the implications of these functional =
differences:
1. Say you use the PB to query an object O that has a collection =
attribute
col with five elements a,b,c,d,e.
Next you delete Objects d and e from col and store O again with=20
PersistenceBroker.store(O);

PB will store the remaining objects a,b,c. But it will not delete d and =
e !
If you then requery object O it will again contain a,b,c,d,e !!!=20
The PB keeps no transactional state of the persistent Objects, thus it =
does
not know that d and e have to be deleted.
(as a side note: deletion of d and e could also be an error, as there =
might
be references to them from other objects !!!)

Using ODMG for the above scenario will eliminate all trouble:
Objects are registered to a transaction so that on commit of the =
transaction
it knows that d and e do not longer belong to the collection. the ODMG
collection will not delete the objects d and e but only the REFERENCES =
from
the collection to those objects!


2. Say you have two threads (applications) that try to access and =
modify the
same object O. The PB has no means to check whether objects are used by
concurrent threads. Thus it has no locking facilities. You can get all =
kind
of trouble by this situation. The ODMG implementation has A Lockmanager =
that
is capable of synchronizing concurrent threads. You can even use four
transaction isolation levels:
read-uncommitted, read-committed, repeatable-read, serializable.


In my eyes the PB is a persistence kernel that can be used to build
high-level PersistenceManagers like an ODMG or JDO implementation. It =
can
also be used to write simple applications, but you have to do all =
management
things (locking, tracking objects state, object transactions) on your =
own.

HTH,

Thomas
=20
=20

> Thanks
> /Lasse
>=20
>=20
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> http://lists.sourceforge.net/lists/listinfo/objectbridge-developers
>=20