|
It is not a bug. Long transaction depends the object exist in cache. Please see http://castor.exolab.org/long-transact.html Thomas -----Original Message----- >From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Clovis Wichoski >Sent: Wednesday, December 26, 2001
11:53 AM >To: [EMAIL PROTECTED] >Subject: Re: [castor-dev]
"Timestamp mismatched!" problem - is there a bug with implementing
Timestampable for dependent objects? > >I have same problem, when in map the cache type is none,
with cache active works well. >Maybe this is a bug with cache/Timestampable? >Clovis >Thomas Yip wrote: >If you think your scenario is not among the existing tests,
please update the tests to include it and send us the "diff -u". >I will take a look at your problem if you do. >Thomas >-----Original Message----- >>From: Richard Holmes (ENZ) [mailto:[EMAIL PROTECTED]]
>>Sent: Monday, November 19, 2001 11:40 AM >>To: [EMAIL PROTECTED] >>Subject: Re: [castor-dev] "Timestamp
mismatched!" problem - is there a bug with implementing Timestampable for
dependent objects? >> >>That's good to hear, but does anyone have any idea
about the timestamp mismatch error for dependent objects? >> >>Cheers, >>R :) >> >>-----Original Message----- >>From: Thomas Yip [mailto:[EMAIL PROTECTED]]
>>Sent: Monday, November 19, 2001 4:33 PM >>To: [EMAIL PROTECTED] >>Subject: Re: [castor-dev] "Timestamp
mismatched!" problem - is there a bug with implementing Timestampable for
dependent objects? >> >>Long transaction is as thread safe as short transaction.
>> >>I think I know which discussion you're referring.
>>He wasn't talk about thread safe, but isolation levels.
>> >>Also, his speculation of lock/cache model of Castor
wasn't exactly accurate. >> >>Anyway, long transaction is as thread safe as short
transaction. >> >> >> >>Thomas >> >> >> >>-----Original Message----- >>>From: Richard Holmes (ENZ) [mailto:[EMAIL PROTECTED]]
>>>Sent: Sunday, November 18, 2001 5:33 PM >>>To: [EMAIL PROTECTED] >>>Subject: Re: [castor-dev] "Timestamp
mismatched!" problem - is there a bug with implementing Timestampable for
dependent objects? >>> >>>Note that this problem ONLY occurs with long
transactions - it's no problem with short ones. I read recently
that long transactions aren't thread safe, but I'm starting to wonder - are
they only usable in certain limited circumstances? >>> >>>Cheers, >>>R :) >>> >>>-----Original Message----- >>>From: Richard Holmes (ENZ) [mailto:[EMAIL PROTECTED]]
>>>Sent: Monday, November 19, 2001 12:12 PM >>>To: [EMAIL PROTECTED] >>>Subject: [castor-dev] "Timestamp
mismatched!" problem - is there a bug with implementin g Timestampable for
dependent objects? >>>Guys - >>>I am doing a few simple tests here at the moment
and I'm having some real problems! >>>The test I'm doing is this: >>>- I have a one-to-many configuration where one
table is dependent on another (and both implement Timestampable) >>>- I load the main record... >>>- modify one of the dependent items >>>- then save the main record again. >>>Boom - I get the old "timestamp
mismatched" error every time, even though I am the only user in a very
small test program. >>>I saw a similar post back in September but the
reported fix was to get the current version of Castor - but even using the
latest CVS snapshot I still get the problem. >>>Any ideas? This one is killing me!!!! >>>Or is it best not to use Timestampable? I
assume then, that my long transactions would be very risky, isn't that right? >>>Cheers, >>>Richard :) >>> >>> >> > |
