Hi,
i am getting the same problems and the given solutions did not work out for
me. To be more specific:
I am trying to use long transactions in a stand alone application to load
data from a database and store the data in XML-files. After closing and
restarting the application the data should be read from the files and stored
(including the modifications, of course) in the database. Because the
application is stoped and restarted there is no way that the dirty checking
could work. So basically i just want to disable dirty checking. Setting each
and every field of my table to dirty="ignore" does not help (and i do not
understand the reason for trying this. Dirty checking in long transactions
is done using a timestamp (says the documentation). So i have to implement
TimeStampable. Which i do not want to in the first place.
As a workaround i tried to use short transaction (read the object from the
database, copy all fields from the object read from xml to the db-object)
and this works fine for simple tables but gets rather messy for nested
tables (remove all child objects deleted in XML-file, add new, etc...
(OR-mapping should make my life easier;) )
After reading the posts quite a few people seem to suffer from this problem.
Maybe it should be an new feature to disable dirty checking for long
transaction if there is no suitable workaround.
please help,
Henning
>>
>> Hi,
>>
>>
>> Nope, your right Conor.
>>
>> a solution would be to set the cache-timeout to a higher time level in
>> your mapping file (or another style)
>>
>> ex.
>> <cache-type type="time-limited" capacity="3"/>
>>
>> or to set your specific field to dirty="ignore" in your mapping file.
>> No change/timestamp checking is done and you can save without
>> an exception
>>
>> Good luck.
>>
>> Robin
>> ----- Origineel Bericht -----
>> Van: "Conor Allen" <[EMAIL PROTECTED]>
>> Datum: Dinsdag, Januari 21, 2003 12:03 pm
>> Onderwerp: Re: [castor-dev] Need Quick Help -- Timestamp mismatched
>>
>> > I believe that for long transactions to work that the cache must
>> > have a version of the object to compare against (for timestamp
>> > checking and to generate the dirty checking update). That means
>> > that if the server process is restarted that the long transaction
>> > will fail. Also, if the object is dropped out of the cache (if you
>> > are using count or time limited cache algorithms) the same thing
>> > will probably happen.
>> >
>> > Am I wrong?
>> >
>> > Conor
>> >
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
