Sigh. Is it still Monday? I'll get it right eventually. Here is what is
(was) actually being done:
tx = odmg.newTransaction();
tx.begin();
profile = new FieldOfficeProfileImpl();
database.makePersistent(profile);
tx.commit();
tx = odmg.newTransaction();
tx.begin();
// Following line does not change behavior:
// profile = getProfileById(profileId);
county = getCountyByFips(fips);
tx.lock(profile, tx.WRITE);
profile.addCounty(county);
tx.commit();
I tried adding tx.lock(county, tx.WRITE) and now it works, though I don't
understand why - county doesn't know about profile, and so is not being
changed. I've never had to lock the child in this situation before. And
it's pretty weird that if I don't lock it, OJB tries to insert it, and if
I do lock it, it doesn't try to insert it!
Moving on, I find the same behavior with delete - when I delete a county
from a profile, I now have to lock the county as well as the profile; in
this case, though, at least the error message tells me what the problem is
(unregistered object found for delete).
I guess this is something that has changed as a result of the ODMG
refactoring? As Martin said, it would be great if release notes could
address this sort of basic change (heck, maybe I was relying on buggy
behavior without realizing it, and it's my own fault).
In any case, thanks for the great tool and the troubleshooting help.
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
Armin Waibel <[EMAIL PROTECTED]>
04/28/2005 11:50 AM
Please respond to
"OJB Users List" <[email protected]>
To
OJB Users List <[email protected]>
cc
Subject
Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
[EMAIL PROTECTED] wrote:
> Three more things:
>
> 1) I have ImplicitLocking turned off
> 2) My pseudocode is wrong: Actually, the parent object is created in a
> different transaction. So it's like this:
>
> tx = odmg.newTransaction();
> profile = new FieldOfficeProfileImpl();
> database.makePersistent(profile);
> tx.commit();
>
> tx = odmg.newTransaction();
> // Following line does not change behavior:
> // profile = getProfileById(profileId);
> county = getCountyByFips(fips);
> profile.addCounty(county);
> tx.commit();
>
This is radical different! How should the second tx recognize the County
and the Profile objects? You set implicite locking off, so the Count
object is not locked and the Profile object too.
> tx = odmg.newTransaction();
tx.begin();
> // Following line does not change behavior:
> // profile = getProfileById(profileId);
> county = getCountyByFips(fips);
tx.lock(county, Transaction.WRITE);
tx.lock(profile, Transaction.WRITE);
> profile.addCounty(county);
> tx.commit();
> 3) According to the log file, county is indeed getting registered as
"new
> dirty":
>
This is strange, because when implicite locking is off no requested
objects should be locked/registered. Or does getProfileById lock the
requested objects?
regards,
Armin
> DEBUG [main] (TransactionImpl.java:316) - Do WRITE lock on object:
> gov.doi.tat.dataobjects.FieldOfficeProfileImpl{64542}
> DEBUG [main] (LockManagerInMemoryImpl.java:292) -
> LM.writeLock(tx-10.100.182.239:83e1e:10389c5d682:-7fff,
> gov.doi.tat.dataobjects.FieldOfficeProfileImpl{64542})
> DEBUG [main] (ObjectEnvelopeTable.java:424) - register:
>
[EMAIL PROTECTED],ModificationState=org.apache.ojb.odmg.states.StateOldClean]
> DEBUG [main] (TransactionImpl.java:362) - call beginTransaction() on PB
> instance
> DEBUG [main] (ConnectionManagerImpl.java:170) - localBegin was called
for
> con [EMAIL PROTECTED]
> DEBUG [main] (ConnectionManagerImpl.java:173) - Try to change autoCommit
> state to 'false'
> DEBUG [main] (ObjectEnvelopeTable.java:143) - PB is in internal tx: true
> broker was: [EMAIL PROTECTED]
> DEBUG [main] (ObjectEnvelopeTable.java:424) - register:
>
[EMAIL PROTECTED],ModificationState=org.apache.ojb.odmg.states.StateNewDirty]
>
> thanks,
> -steve
>
> Steve Clark
> ECOS Development Group
> [EMAIL PROTECTED]
> (970)226-9291
>
>
>
>
> [EMAIL PROTECTED]
> 04/28/2005 09:54 AM
> Please respond to
> "OJB Users List" <[email protected]>
>
>
> To
> "OJB Users List" <[email protected]>
> cc
>
> Subject
> Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
>
>
>
>
>
>
> Martin & Armin,
>
> Thanks for the responses. Some more info:
>
> - The collection in question is a non-decomposed m:n.
> - There actually are two collections which exhibit this problem; in one
> case the child pk is an int, and in the other it's a String. The keys
are
>
> not null or 0 (the child being added was retrieved by pk, and in the log
> file the error message for the INSERT statement shows the expected pk
> value - the way that I found the problem is that the INSERT fails
because
> it violates the pk constraint).
> - In one case, the child is proxyable; in the other case, it is not.
> - I have tried using the default auto-xxx settings and also explicitly
> setting auto-delete and auto-update="none".
> - The child has accept-locks="false".
>
> Here's a repository.xml snippet:
>
> <!-- - - - - - - FieldOfficeProfile - - - - - - -->
>
> <class-descriptor
> class="gov.doi.tat.dataobjects.FieldOfficeProfileImpl"
> table="FIELD_OFFICE_PROFILE"
> factory-method="createFieldOfficeProfile"
> factory-class="gov.doi.tat.dataobjects.SupportDOFactory" >
>
> <field-descriptor
> name="officeId"
> nullable="false"
> column="OFFICE_ID"
> jdbc-type="INTEGER"
> primarykey="true"
> />
>
> <!-- Collections -->
>
> <collection-descriptor
> name="counties"
> element-class-ref="gov.doi.tat.dataobjects.County"
> indirection-table="FIELD_OFFICE_COUNTY"
> auto-update="none"
> auto-delete="none" >
> <fk-pointing-to-this-class column="OFFICE_ID" />
> <fk-pointing-to-element-class column="FIPS" />
> </collection-descriptor>
>
> <collection-descriptor
> name="listedSpecies"
> element-class-ref="gov.doi.tess.dataobjects.TessPopulation"
> indirection-table="FIELD_OFFICE_SPECIES"
> auto-update="none"
> auto-delete="none" >
> <fk-pointing-to-this-class column="OFFICE_ID" />
> <fk-pointing-to-element-class column="ENTITY_ID" />
> </collection-descriptor>
>
> </class-descriptor>
>
> <!-- - - - - - - County - - - - - - -->
>
> <class-descriptor
> class="gov.doi.tat.dataobjects.County"
> schema="SUPPORT"
> table="COUNTY_LUT"
> accept-locks="false" >
>
> <field-descriptor
> name="fullFips"
> column="FIPS"
> jdbc-type="VARCHAR"
> primarykey="true"
> />
>
> ...
>
> </class-descriptor>
>
> <!-- - - - - - - TessPopulation - - - - - - -->
>
> <class-descriptor
> class="gov.doi.tess.dataobjects.TessPopulation" >
> <extent-class
> class-ref="gov.doi.tess.dataobjects.TessPopulationImpl" />
> </class-descriptor>
>
> <class-descriptor
> class="gov.doi.tess.dataobjects.TessPopulationImpl"
> factory-class="gov.doi.tess.dataobjects.TessDOFactory"
> factory-method="createTessPopulation"
> schema="TESS"
> table="SPECIES_DETAILS"
> accept-locks="false" >
>
> <field-descriptor
> name="entityId"
> column="ENTITY_ID"
> jdbc-type="INTEGER"
> primarykey="true"
> />
>
> ...
>
> </class-descriptor>
>
> Code snippet::
>
> county = getCountyByFips(fips);
> tx = odmg.newTransaction();
> profile = new FieldOfficeProfileImpl();
> database.makePersistent(profile);
> profile.addCounty(county);
> tx.commit();
>
> thanks,
> -steve
>
> Steve Clark
> ECOS Development Group
> [EMAIL PROTECTED]
> (970)226-9291
>
>
>
>
> Armin Waibel <[EMAIL PROTECTED]>
> 04/28/2005 04:12 AM
> Please respond to
> "OJB Users List" <[email protected]>
>
>
> To
> OJB Users List <[email protected]>
> cc
>
> Subject
> Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
>
>
>
>
>
>
> Hi Steve,
>
> [EMAIL PROTECTED] wrote:
>
>>Now I remember why I'm always hesitant to upgrade OJB - it seems like
>>there is some fundamental change to how things work.
>
>
> we made a complete refactoring of the odmg implementation in 1.0.2/3,
> because of the many known issues in OJB <=1.0.1 (see release-notes
> 1.0.2/3).
> I did my best not to break backward compatibility. The problem is that
> we don't get much feedback from the ODMG users, so I only can test
> against the OJB test-suite which never could reflect behavior of a real
> OJB application.
> Major changes are noted in release-notes. But you are right, internally
> the odmg implementation changed (better dirty-detection, avoid of
> materialization proxy objects, ...).
>
>
>
>>I hope things are
>>getting more stable, 'cause in the in-between times when I don't have to
>
>
>
>>rework, it's a great tool.
>>
>
>
> My intention was to make it more stable ;-)
>
>
>
>>Here's where I'm stuck now. I just upgraded from 1.0.0 to 1.0.3; I use
>>the ODMG API. I have the following pseudo-code:
>>
>> child = retrieveSomeObjectFromDatabase();
>> tx = odmg.newTransaction();
>> parent = new Parent();
>> database.makePersistent(parent);
>> parent.addChild(child);
>> tx.commit();
>>
>>parent.addChild() does what it sounds like: calls children.add(child).
>>When I commit the transaction, OJB tries to insert a new Child. Can
>>anybody tell me why this might happen? This is, obviously, a
>
> showstopper
>
>>for me. It happens with default caching (i.e. none) and with the
>>two-level cache.
>>
>
>
> I wrote a test-case to reproduce your problem, but I can't. I stumble
> across another bug (OJB-33, will be fixed soon
> http://issues.apache.org/jira/browse/OJB-33).
> Could you post some more details of the used objects. Does the Child
> object use primitive number fields (e.g. int) as PK? Could the PK of the
> Child object be '0'?
>
> Current behavior of ODMG seems that the n-side object will be completely
> ignored: Book -1:n-> Review
>
> Review review = new Review(name);
> TransactionExt tx = (TransactionExt) odmg.newTransaction();
> tx.begin();
> database.makePersistent(review);
> tx.commit();
>
> Date date = new Date();
> byte[] cover = new byte[]{2,3,4,5,6,7,8,9};
> Book book = new Book(name, date, cover);
> tx = (TransactionExt) odmg.newTransaction();
> tx.begin();
> database.makePersistent(book);
> book.addReview(review);
> tx.commit();
>
>
>
>>Other random ODMG questions:
>>At some point, the instructions for adding a new persistent object using
>
>
>
>>ODMG changed; I'm not sure when. It used to say that tx.lock(object,
>>tx.WRITE) would add the object to the db if it wasn't already there, and
>
>
>
>>this is how I've always done it. Now I see that the tutorial says to
>
> use
>
>>db.makePersistent(object), and the code for the two is different. Will
>>tx.lock() still work, or do I have to rewrite all of my DAOs?
>
>
> Yep, this changed. Persist new objects with tx.lock should work too. I
> didn't change the old tests in test-suite and didn't notice side-effects
> (think they use tx.lock too some time to insert new objects).
>
>
>
>
>>Is it true that the (unofficial) feature which actually did allow ODMG
>
> to
>
>>observe auto-delete settings is gone?
>
>
> I didn't take care of this "unkown feature" when refactoring ODMG (the
> official setting was auto-update/delete 'false' in <=1.0.1). But I think
> your setting could cause side-effects, because the objects deleted with
> auto-delete 'true' will not be controlled by ODMG, thus they will not be
> locked before delete.
>
>
>
>>I've always (in OJB ODMG) used
>>cascading delete bounded by appropriate auto-delete settings; now it
>
> looks
>
>>as if I have no choice but to delete each individual object by hand.
>
> True?
>
> When using default behavior - yep.
>
>
>
>> Setting the cascading delete settings by relationship type (1:1, 1:n,
>>m:n) seems extremely weird, and certainly won't be very useful, since
>
> the
>
>>correct delete semantics are always a function of the particular
>>relationship, not of the form of the relationship.
>
>
> Completely agree, I think the introduced settings in OJB.properties are
> nonsense in most cases. Currently the only methods help to improve
> deletion are TransactionExt#setCascadingDelete...
>
http://db.apache.org/ojb/api/org/apache/ojb/odmg/TransactionExt.html#setCascadingDelete(java.lang.Class,%20boolean)
>
>
>
> If your are interested in an official support of auto-delete setting in
> odmg-api please make a feature request on jira. I don't know if this
> will be possible in near future, but will do my best.
>
> regards,
> Armin
>
>
>
>>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]
>
>
>
---------------------------------------------------------------------
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]
