What I am trying to accomplish is to set the "CongDist" class as read-only. I want to be able to make LocationImpl 's point at CongDists, but I never want to update the CONG_DIST table. I have ImplicitLocking=false and accept-locks=false, so I'm surprised to see and UPDATE being generated for CONG_DIST. Is there really no way to prevent this update?
My code was like this: CongDist cd = new CongDist(); cd.setKey(key); cd.setOtherFields(appropriate values); tx.begin(); tx.lock(location, Transaction.WRITE); tx.lock(location.getCongDist(), Transaction.READ); tx.lock(cd, Transaction.READ); location.setCongDist(cd); tx.commit(); The values set in cd matched values already in the database, but an UPDATE was nevertheless generated. I have worked around this by retrieving cd via an OJB query before using it, but I still wonder if there really is no way to mark a table as completely off-limits for update? -steve Steve Clark ECOS Development Group [EMAIL PROTECTED] (970)226-9291 Armin Waibel <[EMAIL PROTECTED]> 11/19/2005 08:13 PM Please respond to "OJB Users List" <[email protected]> To OJB Users List <[email protected]> cc Subject Re: Old bug returns: UPDATE when accept-locks="false" Hi Steve, [EMAIL PROTECTED] wrote: > I am seeing what looks like an old OJB bug resurfacing, and wonder if > anybody can shed some light. > > I have an object with a reference to a read-only lookup table, and also a > collection of entries from another read-only lookup table. Both lookups > have accept-locks="false": > > <class-descriptor class="LocationImpl" ...> > <reference-descriptor name="congDist" class="CongDist" > auto-update="none" auto-delete="none"> > <foreignkey ... /> > </reference-descriptor> > <collection-descriptor name="ecoRegions" class="EcoRegionImpl" > auto-delete="link" auto-update="none"> > <fk-pointing... /> > </collection-descriptor> > </class-descriptor> > > <class-descriptor class="CongDist" schema="SUPPORT" table="CONG_DIST" > accept-locks="false" ... /> > > <class-descriptor class="EcoRegionImpl" schema="SUPPORT" > table="ECOREGION" accept-locks="false" ... /> > > I update an existing LocationImpl like this: > > tx.lock(location, tx.WRITE); > tx.lock(location.getCongDist(), tx.READ); > tx.lock(newCongDist, tx.READ); > location.setCongDist(newCongDist); > > OJB sometimes generates an UPDATE against SUPPORT.CONG_DIST, which fails > because I don't have update permission in that schema. The UPDATE is not > actually attempting to change any values, it's just repeating the existing > ones. I setup a test case similar to yours tx.begin(); tx.lock(book, Transaction.WRITE); tx.lock(book.getPublisher(), Transaction.READ); tx.lock(p_2, Transaction.READ); book.setPublisher(p_2); tx.commit(); Book has a 1:1 reference with Publisher. The Publisher objects are never updated, only the Book object. > I assume that this can't be correct behavior by OJB - it should > never be generating an UPDATE against a class with accept-locks="false". The locking settings are independent from the object state detection in ODMG. E.g. if you set isolation-level to 'none' on class-descriptor the associated objects will never be locked but still inserted, updated, deleted if OJB detects any changes. The 'accept-locks' attribute definition seems strange to me. Does it make sense to skip the locking of an object when the locking call was an implicit one? The current implemented behavior is different. With accept-locks=false OJB will always skip locking (same behavior as isolation-level=none). What do you expect when using this attribute? regards, Armin > The same thing sometimes happens with the ECOREGION table. > > In some cases, the congDist or ecoRegion object in question doesn't > actually come from OJB - it is created independently, but its PK value > matches a value already in the table: > > newCongDist = new CongDist(); > newCongDist.setKey(valid pk from SUPPORT.CONG_DIST); > newCongDist.setOtherData(matching other data from SUPPORT.CONG_DIST); > > We are using ODMG from CVS HEAD (from 1.0.4 branch) as of 4 November. Can > anybody help? > > thanks, > -steve > > Steve Clark > ECOS Development Group > [EMAIL PROTECTED] > (970)226-9291 > > > --------------------------------------------------------------------- > 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]
