On my project, we've done something very similar. We use two separate Castor transactions. One to update the collections (which we do in a quasi-manual way) and a another transaction to persist the core object. We were never able to fully resolve all of the locking conflicts we had otherwise.
--Kevin -----Original Message----- From: Gray Jones [mailto:[EMAIL PROTECTED]] Sent: Friday, April 19, 2002 9:09 AM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] long-transaction I would agree that using long transactions makes things more difficult in castor. We had alot of problems when trying to modify collections within long transactions. However we ended up using them anyway. What we did was basically remove all collections from castor. We end up taking care of them ourselves in manager classes. For instance we have a user manager class that exposes a method getRolesForUser(User user) which gets the collection instead of letting castor load the collection within the mapping.xml. We have a database helper class that all castor operations go through. In the update method of that class we automatically call update for each object. This pretty much dumbs down castor as far as not being able to let it manage relations but still allows you to use long transactions. To me long transactions are what you want in a web/ejb system. But they are difficult to implement. We had the same problems with cocobase about 6 months ago. At the time cocabase didn't support long transactions. They were just beginning to at the time. -----Original Message----- From: Ebersole, Steven [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 4:48 PM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] long-transaction Others may have a different take on this, but in my experience you are best served not using Castor's concept of long transactions. Thats just an opinion. However, as for your issue: I am guessing you are trying to persist AccountK, which has a reference to AccountA. In a long transaction, what you need to do is to make sure all objects (including referenced objects) are "persistable". Generally this is done by calling db.update() on all referenced objects. So say you are trying to update AccountK; you would need to do the following: Database db = ... db.begin(); db.update( AccountA ); db.update( AccountK ); db.commit(); db.close(); Note that if AccountA and/or AccountK reference other objects, you will need to call db.update on them also... ******************************************** Steve Ebersole IT Integration Engineer Vignette Corporation 512.741.4195 Visit http://www.vignette.com ******************************************** -----Original Message----- From: Fabricio Matheus Goncalves [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 18, 2002 3:30 PM To: [EMAIL PROTECTED] Subject: [castor-dev] long-transaction Hi, Im trying to do almost the same described at http://castor.exolab.org/long-transact.html If it help, I have a Account Tree, where AccountA is the root, and AccountK is a ChildNode. Could you help or point me to documentation references on this? org.exolab.castor.jdo.PersistenceException: Object, [ AccountK ] , links to another object, [ AccountA ] that is not loaded/updated/created in this transaction Thanks! ----------------------------------------------------------- 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
