|
I have finally found the actual sequence that
causes this ObjectModificationException. Needless to day the dirty flags made no
difference.
The following sequence creates the row,
updates the row with no address line and then updates again with a value. The
second update throws an ObjectModificationException down at position (3)
referenced in the original email.
If you make the first update set a value longer
than zero then there is no error.
Any ideas?
PersonalInfo personalInfo = new
PersonalInfo();
personalInfo.setFirstName("firstName");
personalInfo.setLastName("lastName");
personalInfo.setAddress1("address1");
m_database.begin();
m_database.create(personalInfo);
m_database.commit();
personalInfo.setAddress1("");
m_database.begin();
m_database.update(personalInfo);
m_database.commit();
personalInfo.setAddress1("address3");
m_database.begin();
m_database.update(personalInfo);
m_database.commit();
m_database.close();
----- Original Message -----
Sent: Monday, August 11, 2003 11:45
AM
Subject: Re: [castor-dev] A new
ObjectModificationException.
This one time, at band camp, Edward Sumerfield
said:
ES>I have a new ObjectModificationException problem. In
updating a row an exception is thrown but when I retry the update (back,
submit) it works. Each is an independent web request with a begin, update and
commit.
ES>
ES>I debugged past all the "if timestamp == timestamp"
issues so I can't work out what this code is trying to do. This is what I
determined from debugging down into SQLEngine. The code below is from
SQLEngine and the bolded line (3) is the throw that is my
problem.
ES>
ES>The first (1) execute performs the update sql with
the correct information in it but apparently gets a zero of less results. The
(2) execute re-reads the data using the primary key and determines that its a
modification exception.
Why?
ES>
ES>org.exola.castor.jdo.engine.SQLEngine.store(Object
conn, Object[] fields, Object identity,Object[] original, Object
stamp)
ES>
ES>(1)
ES>if ( stmt.executeUpdate() <= 0 ) {
// SAP DB returns -1 here
ES> // If no update was
performed, the object has been previously
ES> //
removed from persistent storage or has been modified
if
ES> // dirty checking. Determine which is
which.
ES> stmt.close();
ES>
if ( original != null ) {
ES> stmt =
( (Connection) conn ).prepareStatement( /*_pkLookup*/_sqlLoad
);
ES> if (_logger != null)
_logger.println(_sqlLoad);
ES>
// bind the identity to the
prepareStatement
ES> count =
1;
ES> if ( identity
instanceof Complex )
{
ES>
Complex id = (Complex)
identity;
ES>
for ( int i=0; i<_ids.length; i++
)
ES>
stmt.setObject( count++, idToSQL( i, id.get(i) )
);
ES> } else
{
ES>
stmt.setObject( count++, idToSQL( 0, identity )
);
ES>
}
ES>(2)
ES> ResultSet
res = stmt.executeQuery(); // SELECT ... WHERE primaryKey =
?
ES> int c =
res.getMetaData().getColumnCount();
ES>
if ( res.next() )
{
ES>
stmt.close();
ES>(3)
ES>
throw new ObjectModifiedException( Messages.format("persist.objectModified",
_clsDesc.getJavaClass().getName(), identity )
);
ES>
}
ES>
stmt.close();
ES> }
ES> throw
new ObjectDeletedException( Messages.format("persist.objectDeleted",
_clsDesc.getJavaClass().getName(), identity)
);
ES>}
Ed,
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.
Bruce
--
perl -e 'print
unpack("u30","<0G)[EMAIL PROTECTED]&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
|
