Here is something about the implementation of dirty checking that might help you get
to grips with castor long transactions -
When castor does an update for an object the SQL generated looks like
UPDATE tablename
SET col1 = val1,
col2 = val2,
col3 = val3,
col4 = val2
WHERE pkcol = pkkey AND
col1 = cacheVal1 AND
col2 = cacheVal2 AND
col3 = cacheVal3 AND
col4 = cacheVal4
where the values val<x> are the new values of an object persisted in table tablename
and the values cacheVal<x> are the values loaded into the cache when the object was
first loaded by JDO.
I got caught out on this with date (SQL TIMESTAMP type) values as there was not an
exact match in the where clause - the date translated into yyyy-MM-dd HH:MI:SS.S i.e.
'2003-01-07 00:00:00.0' . If an update fails to update a row, then castor reckons that
the underlying DB has changed since it last loaded the object into memory. And this
tended to fail as the time portion of the SQL timestamp was different. Apparently the
same problem/feature exists with other data types (float ...).
Hope this helps
Conor
-----Original Message-----
From: Karim DAKKI [mailto:[EMAIL PROTECTED]]
Sent: 02 January 2003 17:34
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Object Modified exception while no modification occuring !
I noticed that when I put a null value instead of nothing in MySQL my
problems disappeared !!
Why ?
----- Original Message -----
From: "Micka�l Guessant" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 02, 2003 6:32 PM
Subject: Re: [castor-dev] Object Modified exception while no modification
occuring !
> I added an FAQ entry for this last week :
> Why do I get an ObjectModifiedException when trying to commit a
> transaction ?
>
> The dirty checking engine will throw an ObjectModifiedException when the
> values in the cache and in the database are different. This can happen
> when someone else changed the database content, but also when type
> mapping is not reversible.
>
> For example, if a java timestamp (java.util.Date) is stored as a DATE,
> the time part is lost and the dirty checking will fail. Oracle can not
> tell the difference between an empty String and a null value : if an
> attribute value is an empty String, dirty checking will also fail. Some
> precision loss sometimes occur with floating point numbers.
>
> To avoid this, always use reversible mapping conversions. If this is not
> possible, mark the fields with dirty="ignore" in the mapping file.
>
> Karim DAKKI wrote:
> >
> > ----- Original Message -----
> > *From:* Karim DAKKI <mailto:[EMAIL PROTECTED]>
> > *To:* [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> > *Sent:* Thursday, January 02, 2003 11:54 AM
> > *Subject:* Object Modified exception while no modification occuring !
> >
> > Hello,
> >
> > I am using the last release of Castor for JDO persistence.
> > I am doing read transaction on a database and I am having a
> > ObjectModifiedException !
> >
> > Any clue on where the problem might come from ?
> >
> > org.exolab.castor.jdo.ObjectModifiedException: Transaction aborted:
> > Object of type com.steveg.model.TournamentData with identity 19 has been
> > modified by a concurrent transaction
> >
> > Thanks in advance
> >
>
>
> --
> Mickael Guessant
> Technical Consultant
> http://mguessan.free.fr
> mailto:[EMAIL PROTECTED]
>
> -----------------------------------------------------------
> 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
--
This e-mail is confidential and is intended for the named recipient only. If
you receive it in error please destroy the message and all copies. Kainos
Software Ltd. does not accept liability for damage sustained as a result of
malicious software (e.g. viruses). Kainos does not accept liability for, or
permit, the creation of contracts on its behalf by e-mail, the publication of
any defamatory statement by its employees by e-mail, or changes subsequently
made to the original message. The Company's registered office is located at
4-6 Upper Crescent, Belfast, BT7 1NT, Northern Ireland, Tel +44 28 9057 1100.
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
