This one time, at band camp, [EMAIL PROTECTED] said:
>When a lunch the request the first time every goes well.
>When I launch it a second time, I get:
>"org.exolab.castor.jdo.ObjectModifiedException: Transaction aborted: Object
>of ty
>pe com.datachest.worksafe.model.HazardAssessmentModel2 with identity 11,998
>has
>been modified by a concurrent transaction".
Is there any potential for the second execution to contain fields
whose content is null? Print out the object to the console
(HazardAssessmentModel2 should already have a toString() method)
to see if any of the fields are null.
I may be barking up the wrong tree, here, but it's easy to check
this. If they are null and that turns out to be the problem, this
could be due to a very old defect that should have been fixed about
a year ago.
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
