Hi Steve,
[EMAIL PROTECTED] wrote:
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:
(1) CongDist cd = new CongDist();
(2) cd.setKey(key);
(3) cd.setOtherFields(appropriate values);
(4) tx.begin();
(5) tx.lock(location, Transaction.WRITE);
(6) tx.lock(location.getCongDist(), Transaction.READ);
(7) tx.lock(cd, Transaction.READ);
(8) location.setCongDist(cd);
(9) tx.commit();
The values set in cd matched values already in the database, but an UPDATE
was nevertheless generated.
If you set ImplicitLocking=false and accept-locks=false (pointed out in
my previous mail that the definition/implementation of this setting is
ambiguous) OJB nevertheless use "persistence by reachability" for locked
objects (in your case the Location object).
In line 6 you lock the already existing CD object of location, then you
lock the "new" CD object for Location in line 7 and replace the CD in
Location (8). On commit OJB detect that the CongDist object (of
Location) was replace by a "new" one or by a changed version. In both
cases the Location object will be updated and the CongDist object will
be ignored (I setup a test to verify this). Only when the CongDist
object will be replaced by a different version of the same object, OJB
will update both.
What happens if you comment out line (6)?
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?
Currently it's not possible to declare read-only objects, but you can
declare access="readonly" fields. If all (non-PK) fields are read only
fields, OJB will never write to DB (but if you change read only fields
of persistence capable objects they still will be passed to the cache on
commit).
regards,
Armin
-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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
