Clarifications++ ;)
Mahler Thomas wrote:
Hi again,
some more clarifications ;-)
<snip>
Ok - this sounds VERY much similar to what Hibernate provides in the core.
The ODMG implementation *does not* require any additional
tables in general!
- If you want to use special persistent collections (DList,
DMap, etc) you
must provide additional tables to hold these entities. (AFAIK Hibernate does currently not provide support for the
ODMG persistent
collections. I'm pretty sure that once you start to
implement them you will
end up in providing some tables to hold their data...)
- If you want to run OJB/ODMG on a cluster you need an
additional lock table
in the DB which is used to synchronize transactions across
the cluster.
We do support ODMG persistent collections - but not collections of "everything".
I had at short look at the Hibernate CVS, I did find a DCollection implementation but no DList or DMap implementation. These ODMG collections are meant to store "everything". Thus you'll need some table to store the "pointers" (Identities in OJB) to the referenced entities. I don't know any compliant ODMG implementation that works without a table (or map in OODBMS) for those pointers.
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.
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]
