See inline.
-----Original Message----- >From: Keith Chew [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 22, 2001 7:21 PM >To: [EMAIL PROTECTED] >Subject: Re: [castor-dev] Long Transaction > >Hi > >Ok, there are 2 ways to do this. The hard way is to simulate a short >transaction for a long transaction. Instead of calling update, you: >- load the object (and any dependent objects) >- implement a copy function in your object, which copies attributes from one >object to the other > >This way, you are performing everything (loading, updating) in one >transaction. Castor does not complain. Although this works, but it's kinda >stupid, since you are doing what the persistence layer is meant to do for >you. So, I have taken a closer look at castor's code. > >I found that this piece of code (in ClassMolder.java) is causing 1:1 >relationship to fail: > > // yip: user're pretty easily to run into cache > // integrity problem here, if user forgot to create > // "value" explicitly. Let's put error message here > if ( value != null && !tx.isRecorded( value ) ) > throw new PersistenceException( > "Object, "+object+", links to another object, "+value > +" that is not loaded/updated/created in this transaction"); > >>From the comments, it's meant to protect the cache from being corrupted if >you forget to create the dependent object explicitly. Please read the code a little bit more carefully. The exception is thrown only if ALL of the following conditions meet: 1/ The field object of the data object being update has a different identity than the one in cache 2/ the related is not dependent 3/ autoStore is turned off 4/ the field object exists in are not loaded/queried/updated in the current transaction. It is quite different from what you're trying to describe. I am quite sure that you're certainly creating reference integrity problem. The easiest solution for you is probably to enable AutoStore. (and, you need to call setAutoStore( true ) before the db.begin(), btw) (and, you need to implements TimeStampable interface if you want to use long transaction support) Please also read the document from the website and javadoc again. I remembered I had corrected quite a few of your incorrect concepts on Castor JDO already. I sincerely recommend you to start your project with the tests in the src\tests\jdo\ directory, instead starting from ground up. Removing code that you don't really understand why it is there are not always a good approach in problem solving. Thomas >I commented it out and it seems to perform long updates perfectly. However, >I don't know what side effects it will cause. This is where I need Castor >team's help (from the comments, I suspect this calls for Thomas). > >I will carry on testing the code. Maybe I might find some other hints. > >Keith C > > > > >-----Original Message----- >From: Toni Charlot [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, 23 October 2001 1:40 p.m. >To: [EMAIL PROTECTED] >Subject: Re: [castor-dev] Long Transaction > > >Hello Keith, > >can you share that, por favor. > >-----Original Message----- >From: Keith Chew [mailto:[EMAIL PROTECTED]] >Sent: Monday, October 22, 2001 7:42 PM >To: [EMAIL PROTECTED] >Subject: Re: [castor-dev] Long Transaction > > > >Ignore this mail. I know a way to fix my problem. > >Regards >Keith C > >-----Original Message----- >From: Keith Chew [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, 23 October 2001 11:34 a.m. >To: [EMAIL PROTECTED] >Subject: [castor-dev] Long Transaction > > >Hi > >Same scenarion Product and ProductGroup example. Creation and lookup is >working fine now (all I needed to do was to load ProductGroup in the same >transaction as the one used to create the Product). > >Now I am testing long transaction support. > >When I assign a new ProductGroup to the product and call update(), Castor >reports: > >23.10,11:09:04,954 ERROR [CastorJDOImpl] - >org.exolab.castor.jdo.PersistenceException: Object, myapp.Product@74b0dc, >links to >another object, myapp.ProductGroup@771dc that is not loaded/updated/created >in this transaction. > >>From the source, it writes: > > // yip: user're pretty easily to run into cache > // integrity problem here, if user forgot to create > // "value" explicitly. Let's put error message here > if ( value != null && !tx.isRecorded( value ) ) > throw new PersistenceException( > "Object, "+object+", links to another object, >"+value > +" that is not loaded/updated/created in this >transaction"); > > >This is true because the original ProductGroup was created a while ago in >another transaction. It's kept in cache, so it's impossible to update that >attribute in a long transaction. > >Is this the expected behavior? > >Keith C > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > >----------------------------------------------------------- >If you wish to unsubscribe from this mailing, send mail to >[EMAIL PROTECTED] with a subject of: > unsubscribe castor-dev > ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
