Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Blocker
-
Resolution: Fixed
-
Affects Version/s: 0.9.7
-
Fix Version/s: 1.3 rc1
-
Component/s: JDO
-
Labels:None
-
Environment:HideJ2SDK1.4.2_08 running on Fedora Core 4. the database is SAPDB.
I'm using a compiled version of CVS updated in Aug 10, 2005 with patch ofCASTOR-1179,ShowJ2SDK1.4.2_08 running on Fedora Core 4. the database is SAPDB. I'm using a compiled version of CVS updated in Aug 10, 2005 with patch ofCASTOR-1179,
-
Testcase included:yes
-
Number of attachments :
Description
Hi,
I'm getting trouble with objects loaded in diferent long transactions, in short:
//1st transaction
db.begin();
StateCountry state = db.load(StateCountry.class, "AASTCTPR");
db.commit();
..
//2nd transaction
db.begin();
Country country = db.load(Country.class, "AAAACTBR");
db.commit();
...
//3rd transaction
state.setMyCountry(state);
..
db.begin();
db.update(state);
db.commit();
..
this trouble are same as reported in email:
http://www.mail-archive.com/castor-user@exolab.org/msg00953.html
I attached a test case, that output:
[ClientAPP] populateData executed!
[ClientAPP] 1st operation executed!
[ClientAPP] StateCountry retrieved: ctf.jdo.tc0cw.StateCountry@19ce060 { oid: 'AASTBRPR', name: 'PARANA', myCountry: 'AAAACTBR', timestamp: 1123762499887 }
[ClientAPP] Country retrieved: ctf.jdo.tc0cw.Country@1359c1b { oid: 'AAAACTTS', name: 'COUNTRY FOR TEST', timestamp: 1123762499912 }
[ClientAPP] 2nd operation executed!
[ServerApp] fails with message: Nested error: org.exolab.castor.jdo.PersistenceException: Object, ctf.jdo.tc0cw.StateCountry@19ce060 { oid: 'AASTBRPR', name: 'PARANA', myCountry: 'AAAACTTS', timestamp: 1123762499887 }, links to another object, ctf.jdo.tc0cw.Country@1359c1b { oid: 'AAAACTTS', name: 'COUNTRY FOR TEST', timestamp: 1123762499912 } that is not loaded/updated/created in this transaction: Object, ctf.jdo.tc0cw.StateCountry@19ce060 { oid: 'AASTBRPR', name: 'PARANA', myCountry: 'AAAACTTS', timestamp: 1123762499887 }, links to another object, ctf.jdo.tc0cw.Country@1359c1b { oid: 'AAAACTTS', name: 'COUNTRY FOR TEST', timestamp: 1123762499912 } that is not loaded/updated/created in this transaction
[ClientAPP] testRetrieveMany 3rd operation failed on server with message: Nested error: org.exolab.castor.jdo.PersistenceException: Object, ctf.jdo.tc0cw.StateCountry@19ce060 { oid: 'AASTBRPR', name: 'PARANA', myCountry: 'AAAACTTS', timestamp: 1123762499887 }, links to another object, ctf.jdo.tc0cw.Country@1359c1b { oid: 'AAAACTTS', name: 'COUNTRY FOR TEST', timestamp: 1123762499912 } that is not loaded/updated/created in this transaction: Object, ctf.jdo.tc0cw.StateCountry@19ce060 { oid: 'AASTBRPR', name: 'PARANA', myCountry: 'AAAACTTS', timestamp: 1123762499887 }, links to another object, ctf.jdo.tc0cw.Country@1359c1b { oid: 'AAAACTTS', name: 'COUNTRY FOR TEST', timestamp: 1123762499912 } that is not loaded/updated/created in this transaction
[ClientAPP] Objects retrieved for delete: [ctf.jdo.tc0cw.StateCountry@164dbd5 { oid: 'AASTBRPR', name: 'PARANA', myCountry: 'AAAACTBR', timestamp: 1123762499887 }, ctf.jdo.tc0cw.StateCountry@125844f { oid: 'AASTBRSP', name: 'SAO PAULO', myCountry: 'AAAACTBR', timestamp: 1123762499897 }, ctf.jdo.tc0cw.Country@9cb0f4 { oid: 'AAAACTBR', name: 'BRAZIL', timestamp: 1123762499879 }, ctf.jdo.tc0cw.StateCountry@11978b { oid: 'AASTUSTX', name: 'TEXAS', myCountry: 'AAAACTUS', timestamp: 1123762499904 }, ctf.jdo.tc0cw.StateCountry@26dbec { oid: 'AASTUSCL', name: 'COLORADO', myCountry: 'AAAACTUS', timestamp: 1123762499909 }, ctf.jdo.tc0cw.Country@f42ad0 { oid: 'AAAACTUS', name: 'UNITED STATES', timestamp: 1123762499900 }, ctf.jdo.tc0cw.Country@1309e87 { oid: 'AAAACTTS', name: 'COUNTRY FOR TEST', timestamp: 1123762499912 }]
[ServerApp] fails with message: The object of type ctf.jdo.tc0cw.StateCountry is not persistent – it was not queried or created within this transaction
[ClientAPP] removeData delete operation failed on server with message: The object of type ctf.jdo.tc0cw.StateCountry is not persistent – it was not queried or created within this transaction
//end of output
Note that this trouble occurs for update and delete.
Attachments
Issue Links
| This issue depends upon: | ||||
| CASTOR-1203 | Calculation of priority to execute create and delete statements at commit returns wrong results. |
|
|
|
Activity
yes, maybe, but here we have direct reference and no polymorphism, maybe attached patch that includes a test case, can be used to test the issue in CASTOR-1195 too.
please ignore the testCase.tar.gz file attached, I wrong attached this file, now I attached using the patch pattern, thanks to Ralf, that without his help the creation of patch dont be possible, 
hi
I added a new patch, with changes in ClassMolder and PersistanceCapableRelationResolver, and created tests for
Unidirectional, Simple Bidirectional and Complex Bidirectioal, at this, I solved the problem with long transactions without autostore, but we need discuss more about things in this patch:
1) load ClassMolder based on value (maybe solves other issues for troubles with polymorphism), see patch to better understand.
2) who needs control bidirectional references, user or Castor, if Castor who deal with it, when user control the bidirectional references like in this patch?
note: in creation of this testCase if found more two issues one with dirty=ignore and other with rollback of timestamps, I will make a more simple testCase for both after. and create new ISSUES, 
I dont mention that the attached testCase pass in all test of JDO CTF,
I removed some of the database constraints as they made it imposible to remove car/order tables. I also removed not null constraint at OrderItem and modified testRemoveDataComplexBidirectional() mthod to allow to remove the test records. I only modified mysql.sql script but changes need to be applied also to sapdb.sql script.
Still tests could not be run suggessfull at the first run as the removeXxxx() methods fail at the first execution. This needs to be changed. I'm also not sure if we cover all usecases as bidirectional 1:n relation is only tested between classes that depend on each other (Order / OrderItem).
I did not have time to look at your modifications at ClassMolder and PersistanceCapableRelationResolver yet.
In addition I miss a comment from Werner
question to think, I will numerate for us better discuss:
1) But if the constraint in database cant be removed? e.g: this is a requirement for the system, and DBA dont allow that, he is the master,
the testRemoveDataComplexBidirectional are write with this thing in head, when, constraint in database cant be changed.
2) The remove appears first, just to look how the data stay in database after tests ends, the order can be changed without problem. (its because troubles with dirty explained at CASTOR-1206).
3) About relations, this testCases shows the user controling relations, then new doubts appears, we can put the control of relations inside Castor, but how deal with that when the user control the relations like in this testCase?
4) About autoload of relations, how deal with that, when the user do e.g: (assumes that OrderItem dont depend of Order) user executes
db.update(Order) and for each OrderItem of this Order executes db.update(orderItem) and db.update(orderItem.myProduct), the user put objects in wrong order, then the autoload will load objects that will be updated after in same transaction, we may have a Priority control here, like for executing SQL statements?
5) About ClassMolder and PersistanceCapableRelationResolver I loaded the ClassMolder of PersistenceCapable based in Class of value, this way we get the correct ClassMolder for value, before, only gets ClassMolder based on map, this works well if we dont have Class hierarchy, with Class hierarchy we get wrong results. then checking value solves many things, maybe this idea solves other troubles with hierarchy in Castor. and change the name of same variables and parameters for the code became more readable.
the testRemoveDataComplexBidirectional are write with this thing in head, when, constraint in database cant be changed.
2) The remove appears first, just to look how the data stay in database after tests ends, the order can be changed without problem. (its because troubles with dirty explained at to 1) at your application you may set whatever constraint you like but should also take into account that some can prevent records to be deleted at all. If you have set such constraints it will also be imposible for castor to delete them. As our test cases need to be executed multiple times without creating a new database such constraints are not acceptable here. E.g. there had been no way to delete an order or orderItem with the constraints you have set. Having said that there also may be combinations of constraints that would allow to delete records with SQL statements but castor can not handle.
to 2) i suggest the following order for your test:
1. remove table entries with passthrough SQL statments not throwing excdeptions when tables are empty
2. create your test data
3. execute update tests
4. remove your test data (the remove method as it currently is)
With this you always have the same test conditions even if something fails at steps 2, 3 or 4. If you like to see data in tables you may comment to execute step 4.
3) to 5) I do not understand that
I wonder if this ends up being the same fundamental problem as
CASTOR-1195has...CASTOR-1195has...