Hi Thomas Yes, I have looked further and you are correct. 4/ is not true. The field is set is another transaction. What I cannot understand is how do we set the field in the same transaction as the update()??
An update() is meant to update an object that is modified outside the transaction scope, eg website application. If the field has to be set in the same transaction, why use update() at all? I think there's a programming logic gone bad somewhere. But I will now look into the src\tests\jdo\ directory. Maybe I can find some clues there. =) Keith C. -----Original Message----- From: Keith Chew [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 23 October 2001 4:19 p.m. To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Long Transaction Hi Thomas Thanks for your patience and looking at my mail. I am basically working on the example (Product, ProductDetail) and trying to recreate my problems from my app. So, if something works in the example, then it's my fault. But I'll look at the tests next. Oh, I have made a mistake in my previous mail. I mentioned dependent object, but my concept is wrong. I will use the correct term from now on. Ok, let's move on: 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. 1/ is true because I am updating a new object with new id. 2/ is true becasue there's no "depends" attribute 3/ is true because I am not using auto store 4/ could be a problem. I tried loading the object in the same transaction, but this exception is still thrown. Heck, I even tried loading the entire table in the same transaction, but still no joy. But you have given me somewhere to look. I will try to trace the problem. PS: Of course you would remember me. You gave me the "non water resistent watch" analogy. Well, now I am knowing Castor a lot better. Thanks again. And yes, I know AutoStore will solve my problem, but I do not want to use it. It's too easy to re-create a record that is suppose to be deleted. Regards Keith C -----Original Message----- From: Thomas Yip [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 23 October 2001 4:07 p.m. To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Long Transaction 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 ----------------------------------------------------------- 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
