That looks like it would be a bit more attractive but it didn't work for me
either.  Just knowing that somebody else had a similar problem helps me
cope.

I get the following exception:

org.exolab.castor.jdo.DuplicateIdentityException: update object which is
already in the transaction
        at
org.exolab.castor.persist.TransactionContext.markUpdate(TransactionContext.j
ava:906)
        at
org.exolab.castor.persist.TransactionContext.update(TransactionContext.java:
980)
        at
org.exolab.castor.jdo.engine.DatabaseImpl.update(DatabaseImpl.java:353)


-----Original Message-----
From: Keith Chew SL [mailto:[EMAIL PROTECTED]]
Sent: Saturday, November 24, 2001 7:05 PM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Long Transaction nightmare


Hi Toni

I encountered a similar problem a while ago. The reason for this is because
Castor needs to know about employee (30) in the update transaction. This
will allow it to do the preserve referential integrity.

Your "works, but not elegant at all" approach can be made more elegant by:
     public void save(Employee emp) {
         Database db;
         db.begin();
         Skill s = db.load(Skill.class, new
Integer(emp.getSkill().getId()));
         update(emp);
         db.close;
     }

All you need to do is to load the dependent object in the transaction. Give
it a go and let me know if it works. I agree with you that a single update()
should be enough, but this is one step sloser to that goal.

Keith


> -----Original Message-----
> From: Toni Charlot [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, 25 November 2001 12:18 p.m.
> To: [EMAIL PROTECTED]
> Subject: [castor-dev] Long Transaction nightmare
>
>
> I have the following scenario
>
> looking at and employee record:
> --> trans1:
>         Employee emp;
>         db.begin
>         emp= db.load(Employee.class, new Integer(70));
>         db.commit();
>         db.close();
>
> Grabbing a particular skill from an existing list in the DB
> --> trans2:
>         Skill sk;
>         db.begin
>         sk= db.load(Skill.class, new Integer(30));
>         db.commit();
>         db.close();
>
> assign skill sk to Employee emp
>         emp.setSkill(sk);  //notice that's outside of any transaction,
> [long]
>
> user wants to save changes made to tst
> --> trans3: /** works, but not elegant at all */
>     public void save(Employee emp) {
>         Database db;
>         db.begin();
>         Employee empTmp = (Employee)db.load(Employee.class, new
> Integer(emp.getId()));
>         Skill s = db.load(Skill.class, new
> Integer(emp.getSkill().getId()));
>         empTmp .setSkill(s);
>         db.commit();
>         db.close;
>     }
>
> shouldn't the trans3 be:
>     public void save(Employee emp) {
>         Database db;
>         db.begin();
>         db.update(emp);
>         db.close();
>     }
>
> If I do the above, castor tries to create a new Skill with primary key 30.
> both Employee and Skill implements TimeStampable.
>
> Employee & Skill have a many-many relationship
> Table Employee --> empKey
> Table EmpSkills --> empKey, skillKey
> Table Skill --> skillKey
>
> Thank you.
>
> -----------------------------------------------------------
> 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

Reply via email to