Hi again, <snip/> > > Also remeber that allowing for reattaching lazy collections > to a new session "behind > your back" will mess up transaction boundaries, unless if you > let ALL transactions > use the same objects and require that you perform the locking > inside the JVM on objects instead.
OJB manages the locking of lazy objects and Collection by a deferred locking mechanism. We are not using database mechanism for locking (e.g. row level locking) but our own LockManager mechanism. We are not using any JVM locking or synchronization mechanisms! > > As I understand it, OJB handles it by doing locking in JVM > but this changes the > database transaction isolation semantics You are right, OJB is able to provide Isolation levels for Object Transactions that are completely independ of the database transaction isolation! We have done this to clearly separate concerns. We don't want to mix RDBMS transaction semantics with Object level transaction semantics! One big problem with database tx isolation is that different vendors provide completely different semantics. EG. DB2 has a mechanism called lock escalation that locks the whole table if too much rows are locked. We don't want such things to happen on the Object level! > and it is a solution > that does not scale > across multiple machines and it requires much more overhead > in the Java code > (ie. in the implementation of OJB) The OJB solution does scale well. The LockManager implementation is very simple and so the overhead is not a problem. Our LockManager architecture uses the same concepts as the lock service of highly scalable OO databases like Objectivity. cu, Thomas > > > > There is also no way to clear cache > > other than nullifing the Session which also leads to the > lazy collection > > problem above. This is all probably not a problem if you > load and release > > all data, including lookup data, with each use case e.g. > unit of work. > > I was also dissapointed that there is no mechanism to > > synchronize the cache with recent commits; > > Is that not what session.refresh() is for ? > (or do you want a session wide refresh() method? - that would > be slow!?!) > > > another reason you always have to > > close the Session because it's the only way to remove stale > cache and get up > > to date db data. > > Again - you could use e.g. session.clear() for removing stale data... > > Thanks for the comments and best regards, > Max > > > > > >>-----Original Message----- > >>From: Mahler Thomas [mailto:[EMAIL PROTECTED] > >>Sent: Monday, November 17, 2003 4:53 AM > >>To: 'OJB Users List' > >>Subject: RE: Persistence frameworks > >> > >> > >>Hi Max, > >> > >> > >>>Hi! > >>> > >>>Just want to ask/clarify some stuff on this one - sorry for > >>>the late "answer" ;) > >>> > >>> > >>>>Happily: > >>>> > >>>>OJB provides much more flexibility in caching; provides > >>> > >>>object-space > >>> > >>>>transactions in a non-managed environment (if you are > >>> > >>>running in a J2EE > >>> > >>>>container which provides JTA than this is probably a wash > >>> > >>>as you will > >>> > >>>>probably want to use JTA for transactions and both OJB and > >>> > >>>Hibernate > >>> > >>>>support using JTA); > >>> > >>>May I ask what object-space transactions you mean OJB provides that > >>>Hibernate does not ? (Is it the ODMG stuff you are > referring to, which > >>>requires extra tables in the db ?) > >> > >>The three high-level APIs (ODMG, JDO and OTM) provide full > object level > >>transaction management. They provide a full instance > life-cycle model as > >>specified by the JDO spec. > >>By using JTA these tx managers can be integrated into J2EE > containers or > >>other JTA compliant tx managers. > >> > >>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. > >> > >><snip> > >> > >>>>The biggest thing is a core design difference where OJB is > >>>>designed to be very flexible and allow you to get exactly > >>> > >>>what you need > >>> > >>>>whereas Hibernate is designed to do it one way and make > >>> > >>>that one way > >>> > >>>>match what most people need. > >>> > >>>Yes - that's probably the biggest difference between OJB and > >>>Hibernate. > >>>Hibernate want KISS, OJB want ultimate flexibility ;) > >> > >>My impression is that this was true some time ago, but you are > >>adding a lot > >>of pluggable features into Hibernate these days (Field > access strategies, > >>Cache implementations, etc.). > >>I don't believe that a KISS approach works for a heavy duty O/R > >>tool. Users > >>work in so many different environments with so many different > >>requirements... > >>So IMO best thing to do is to design for ultimate flexibility > >>from scratch. > >> > >> > >> > >> > >>> > Finally, the licensing issue is either a > >>> > >>>>huge difference or a doesn't-matter depending on your > >>> > >>>company's lawyers > >>> > >>>>and/or how you intend to distribute the application -- OJB is ASL > >>>>Hibernate is LGPL. > >>> > >>>Just remember to read of license faq which states that > >>>Hibernate can be used > >>>in any project commercially or not - and without making your > >>>project opened source! > >>> > >>>The only "limitations" is that you cannot fork Hibernate > >>>(write ya' own persistence engine) > >>>and that if you make some improvements to hibernate you > >>>should submit them back > >>>to the project. > >> > >>IMO this *is* a limitation! OJB was build to allow users to write > >>their own > >>persistence engines by reusing our code-base. Apart from > providing object > >>orient persistence API's it's also meant as a construction kit for > >>persistence layers. > >> > >> > >>>>On the other hand Hibernate provides two things that OJB > >>> > >>>does not -- a > >>> > >>>>forthcoming book > >> > >>There are already several books available that have a > decent coverage of > >>OJB. > >>(e.g. > >>http://www.amazon.com/exec/obidos/ASIN/0596003285/qid%3D1054656123 > > > > /sr%3D2-1/ > > ref%3Dsr%5F2%5F1/102-4902036-7120135 and > > > http://www.amazon.com/exec/obidos/tg/detail/-/1861007817/qid=1 > 054655953/sr=8 > > -1/ref=sr_8_1/102-4902036-7120135?v=glance&s=books&n=507846). > > > > A book exclusive covering OJB is also under discussion. > > > > > >>and the ability to easily hand it a JDBC > >>Connection and > >> > >>>have it use that Connection (this can be done via some voodoo-like > >>>runtime configuration of OJB, but isn't a good idea -- > > > > > > Of course OJB allows you to provide your own connection > lookup mechanism. > > It would take about 5 Minutes to write a ConnectionManager > implementation > > that can work with user connections. Until today nobody > requested this > > feature... > > > > According to Clark's law "sufficiently advanced technology is > > indistinguishable from magic" > (http://c2.com/cgi/wiki?ClarkesLaw). But the > > OJB metadata and configurtaion framework applies patterns > that are known for > > ages and covered by tons of textbooks > > > (http://c2.com/cgi/wiki?MetaObjectProtocol,http://c2.com/cgi/w > iki?TheArtOfTh > > eMetaObjectProtocol). So calling it voodoo is really giving > to much credit > > to OJB ;-) > > > > > > > >>OJB > >>pretty much > >> > >>>needs to know the JNDI lookup for your DataSource in its > >> > >>configuration). > >> > >>ok - did not knew that. I seem to remember using OJB before > >>without requiring > >>any kind of JNDI!? > > > > > > Correct, JNDI is not mandatory, it's an option. > > > > cheers, > > Thomas > > > > > >> > >>Just my 2 cents ;) > >> > >>/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] > > > > > --------------------------------------------------------------------- > 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]
