Well, now you do ;) Hibernate does have an ODMG compliant implementation and
does not have an extra table....as we understand the ODMG spec, the "store 'everything'"
feature is not required to be ODMG compliant.
If an OJB user chooses not to use the "store everything" collections, he wont't have to create the DList tables! OJB/ODMG has full support for using ordinary (i.e foreign key based) 1:n and m:n collections.
But if a user wants to use full fledged "store everything" maps and collections he can do so by using the special tables.
IMHO this freedom of choice is a plus for OJB and not a disatvantage!
Correct, never claimed otherwise. Hibernate just focus more on practical usable stuff than less practical stuff ;)
What part of the ODMG spec makes you believe that "store everything" is not mandatory for DList & co?
Here you are hitting my limits ;) I don't know the ODMG spec by heart - but i'll see if I can dig it out ;)
Another reason: The named roots concept. AFAIK Hibernate implements named roots with a special persistent class "Name".
The idea of your "Name" class is very close to the OJB "NamedRootsEntry". They both provide a mechanism to contain a pointer to "everything".
So for the Named roots you agree that ODMG requires pointers to everything but for DCollections you don't?
Yes - Our Name class supports naming for persistent classes, not for "everything"
Another thing that I don't understand yet:
According to the ODMG spec the Name instances must be stored somewhere to be persistent. Where do you store those Name instances?
I see there is a "Name.hbm.xml". Does this mean the Name instances are persisted to the Database?
Yes they are. But my problem with OJB storing stuff in the db is regarding the locking mechanisms....you store "locks" in the db, right ? Not just "data".
I guess we again need more clarifactions ;-)
yes ;)
cu, thomas
So, I'm not exactly sure why you need those extra tables for synchronizing information
that the database already has elsewhere (at least that is how I see that information).
(but again that depends on what you mean exactly by synchronized transactions across
a cluster)
The special thing about OJB object level transaction is that they entirely
kept on the java object level.
So if an OJB ODMG transaction locks an object there is no database row lock
!
Instead OJB uses an object level Lock manager. If you you are working in a
single VM it's easy to work with a hashtable to keep the locks.
If you are running on a cluster you need a LockManager that maintains the
locks for all JVMs in the cluster.
The current LockManager implementation uses a database table to hold the
lockentries.
As the LockManager is pluggable user can implement their own stuff if they
don't like to keep an extra table.
Ok (but this stuff is really not needed for most enterprise applications IMHO)
Best regards, Max
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
