August Detlefsen wrote:
I understand the need for dirty checking to manage concurrency across
many transactions, but what is the need for dirty checking within the
bounds of one transaction?
In my case, I originally attempted to create the object, get the newly
created ID, us the ID to set a field within the same object, then
commit -all in the course of a single short transaction. The
ObjectModifiedException cannot be from another transaction trying to
modify the same object because in this case the create() call has not
even committed yet so there is no way for another transaction to even
know it exists.
The problem is that the db.create( page ) took place in the first tx. Therefore, the second tx will not be aware of it until db.update( page ) is called. Beyond that, I haven't seen the object mapping for the Page object so it's difficult for me to comment. Please post the object mapping for the Page object. I'm wondering what field types make up the Page object. An ObjectModifiedException can be thrown when a field fails Castor's dirty check (which uses .equals()). This can occur when using fields of type float, double, date, etc. Isolate these field types by instructing Castor not to perform its dirty check on them like so:
<sql name="foo" type="date" dirty="ignore" />
See if the ObjectModifiedException goes away after taking this step. This might then lead you down the road of locating the actual problem. I'm very curious to know what you find.
You are right about the second code example, it is pure hack! But it was the only way I could get around that exception. I would love to do it the right way, believe me. Is this is actually a bug then?
I cannot tell if this is bug yet. We need to undergo a thorough investigation before making that determination.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project http://www.castor.org/
Apache Geronimo http://incubator.apache.org/projects/geronimo.html
----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
