Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
[EMAIL PROTECTED] wrote: 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? 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. Armin has fixed a number of bugs in OJB in the ODMG area, so ODMG should generally be much more stable in 1.0.3 than 1.0.0. However, I believe some bugfixes had to be made on the expense of modified configuration defaults. Especially for the auto-xxx settings in the repository file. Armin will have more info on this, but please have a look at the docs and see if you get past your upgrade frustration: http://db.apache.org/ojb/docu/guides/repository.html See especially: class-descriptor The accept-locks attribute specifies whether implicit locking should propagate to this class. Currently relevant for the ODMG layer only. reference-descriptor auto-update For ODMG-api none is mandatory (since OJB 1.0.2). auto-delete For ODMG-api none is mandatory (since OJB 1.0.2). collection-descriptor auto-update For ODMG-api none is mandatory (since OJB 1.0.2). All changed/required settings sould also be self-documented in the repository.dtd comments. Be sure to upgrade repository.dtd, repository-internal.xml, OJB.properties and OJB-logging.properties between releases. Regards, Martin P.S. I fully agree with you that changed config defaults between minor releases should generally be avoided. In this case I think some bugs were considered harmful enough to motivate the frustration... We should also improve the website with migration HOWTO:s for releases to avoid the effort to discover this the hard way, like you did. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
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-classcolumn=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-classcolumn=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 ojb-user@db.apache.org To OJB Users List ojb-user@db.apache.org 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
Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
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();
3) According to the log file, county is indeed getting registered as new
dirty:
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 ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
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-classcolumn=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-classcolumn=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,
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 ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
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-classcolumn=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-classcolumn=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
Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
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 ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
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 ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
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
Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
[EMAIL PROTECTED] wrote:
Sorry for so much volume, but I spoke too soon.
The only thing that changes when I add tx.lock(county, tx.WRITE) is that
it does an update instead of an insert. In fact, it does this even if I
request a READ lock. So, in summary, this code:
tx = odmg.newTransaction();
tx.begin();
county = getCountyByFips(fips);
tx.lock(profile, tx.WRITE);
tx.lock(county, tx.READ);
profile.addCounty(county);
tx.commit();
does correctly generate an INSERT INTO FIELD_OFFICE_COUNTY (the m:n
association table). But it also incorrectly generates an UPDATE
COUNTY_LUT. This is with ImplicitLocking=false and auto-update=none,
as well as accept-locks=false in the County class descriptor.
it's a bit confusing, but it sounds like a bug. Please could you post
the relevant part of the used class-descriptor's (PK fields + all
references) and the code of your test (or similar pseudo code) to my
account (post the CLD's inline, the apache server doesn't like
attachments). I will setup a test case to reproduce your problem.
regards,
Armin
-steve
Steve Clark
ECOS Development Group
[EMAIL PROTECTED]
(970)226-9291
[EMAIL PROTECTED]
04/28/2005 12:48 PM
Please respond to
OJB Users List ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
cc
OJB Users List ojb-user@db.apache.org
Subject
Re: Problems with collections in ODMG - just upgraded to OJB 1.0.3
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 ojb-user@db.apache.org
To
OJB Users List ojb-user@db.apache.org
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]
Problems with collections in ODMG - just upgraded to OJB 1.0.3
Now I remember why I'm always hesitant to upgrade OJB - it seems like there is some fundamental change to how things work. 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. 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. 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? Is it true that the (unofficial) feature which actually did allow ODMG to observe auto-delete settings is gone? 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? 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. 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]
