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. > 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. <snip/> > > > So IMO best thing to do is to design for ultimate > flexibility from scratch. > > Well - that's the difference between the Hibernate mindset > and OJB IMHO. > And thus I think we will agree to disagree on this point ;) I agree ;-) -Thomas <snip/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
