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 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 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]
