In addition, as a check, I preload the dependent objects just to make sure that it is still in the database before performing an update. Castor does not seem to do this. ie:
(1) read ObjectA from website (2) set new dependent ObjectB for ObjectA (3) remove ObjectB from DB (4) preload ObjectB before update (5) perform update on ObjectA (4) and (5) are in the same transaction. Basically step (4) allows me to catch step (3) and throw an exception before reaching step (5). The preload is also done on create (read my previous mail). This is required if you have setAutoStore() to false because you have to ensure that the dependent objects are loaded in the same transaction. Regards Keith C -----Original Message----- From: Keith Chew [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 23 October 2001 3:21 p.m. 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. 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
