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]
