This one time, at band camp, Allan Bond said:

AB>I have a problem updating a many-many relationship in a long
AB>transaction.  Basically, I have two objects in a many-many relationship:
AB> 
AB>Registration *------* Class
AB> 
AB>A user is presented with a static list of Classes (not generated from
AB>the database).  After the user submits his selections, I use the classId
AB>to load each of the selected Classes. Then, I add the classes to a new
AB>Registration object and I also add the Registration to the Classes like
AB>this.
AB> 
AB>      // iterate through selected classes and add them to a new
AB>Registration object
AB>      if (c != null) {
AB>        for (int x = 0; x < c.length; x++) {
AB>          Integer classId = new Integer(c[x]);
AB>          Class aClass = new Class();
AB> 
AB>          // get class from database based on passed ID
AB>          try {
AB>            db.begin();
AB>            aClass =
AB>(Class)db.load(java.lang.Class.forName("net.goldengoal.model.Class"),cla
AB>ssId);
AB>            db.commit();
AB>          }
AB>          catch (Exception e) {e.printStackTrace();}
AB> 
AB>          // add class to Registration and vice versa
AB>          aRegistration.addClass(aClass);
AB>          aClass.addRegistration(aRegistration);
AB>        }
AB>      }
AB> 
AB>Then, the user is taken to a confirmation page.  After clicking the
AB>'confirm' button, I attempt to update the Registration object like this:
AB> 
AB>    db.setAutoStore(true);
AB>    db.begin();
AB>    db.update(aRegistration);
AB>    db.commit();
AB> 
AB>This works as long as there are no Registrations using the same Class
AB>combination.  For example, if I create a Registration that includes
AB>Class A and Class B, it works fine.  However, when I try to create
AB>another Registration that includes Class A and Class B, I receive the
AB>following exception:
AB> 
AB>org.exolab.castor.jdo.DuplicateIdentityException: update object which is
AB>already in the transaction

Allan,

Because I haven't seen all the code I don't claim to understand the app,
but because you're using setAutoStore( true ), all reachable objects
(meaning all objects in the transaction context) will be stored upon
calling commit(). Is there a reason that you're using this? What happens
when you don't use it?

Also, notice that you're using a key generator. What happens if you
remove the key generator? 
Bruce
-- 
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

----------------------------------------------------------- 
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
        unsubscribe castor-dev

Reply via email to