Re: Stale data
Re: Stale data
- Subject: Re: Stale data
- From: Corin Lawson <email@hidden>
- Date: Mon, 1 Oct 2007 12:11:05 +1000
Hi Gordon,
Thanks again, sorry I should have been more specific.
Indeed, that's how I have and do test it, but with or without the
code you suggested I'm unable to replicate the problem. I was hoping
that there's was a simple switch I could turn on to show diagnostics
regarding fetching and caching (so that I may gain a better
understanding). I admit I'm searching for the 'path of least
resistance' which is the reason I haven't delved into Wonder. Perhaps
I don't appreciate the benefits of Wonder but I wish to avoid the
'bells and whistles.'
For a long time I thought there was a fault in my logic, but it is
now clear to me that the framework is not behaving the way I thought
it does... I've read and reread the documentation but the problem
only shows up in production operations. And I can't rely on
operations staff to report the problem in a timely and accurate
fashion. The system is not supposed to be a beta version!
Pardon the vents of frustrations but without a test case every time I
implement a 'fix' (it's not a bug unless it can be replicated,
right?) and turn my mind to other problems the problem turns up once
more. I can't help but feel that I'm running in circles or backwards.
(That reminds me of my back stroke at high school water sports... I
could never swim in a straight line!)
I'll continue my reading, and consider using Wonder. If I find the
time I'll create an automated test scenario and keep my fingers crossed.
Cheers,
Corin.
On 29/09/2007, at 12:36 AM, Gordon Belray wrote:
Hi Corin,
this might seem remedial, but the way I tested it when running
multiple instances of an application was to fetch in the data on
one instance, change the relationship on another, and then refetch
it to see if the relationship was updated. In your case, you would
need to change it on the non-WO app.
You may also want to look into some change notification frameworks
such as Wonder's ERChangeNotificationJMS. Quite a lot has been
written on the topic of fresh data, take a look at this:
http://wiki.objectstyle.org/confluence/display/WO/EOF-Using+EOF-
Caching+and+Freshness
Gordon
On 28-Sep-07, at 5:14 AM, Corin Lawson wrote:
Thanks Gordon,
I'll be sure to try it, but how do I test?
Cheers,
Corin.
On 27/09/2007, at 11:24 PM, Gordon Belray wrote:
Hi Corin,
this has worked for me in the past:
EOFetchSpecification fs = new EOFetchSpecification
("SomeObject", null, null);
fs.setRefreshesRefetchedObjects(true);
String [] keypaths = {"toRelationship"};
fs.setPreftechingRelationhsipKeyPaths(new NSArray(keypaths));
cheers,
Gordon
On 27-Sep-07, at 1:12 AM, Corin Lawson wrote:
Hi List,
I have been experiencing the following problem for some time now
and have not been able to establish a pattern or replicate the
problem, let alone solve it, please help.
The symptom is that a certain process fails because the WO
(5.2.4) app is using stale or cached data, where the data has
been changed in the database (mysql 5) by a separate (non-WO)
system. The stale data has been known to persist for over an
hour. The data in question is contained in an entity that is a
to-many relationship of another entity which is being fetched.
From inspecting the standard output with
DEOAdaptorDebugEnabled=true I see that in the majority of cases
the entity in question and all it's related entities are being
fetched each time that the process is executed. But in other
cases (which are indistinguishable from the other cases AFAIK)
only the entity is fetched and none of it's related entities. In
all my test cases it works as I expect it to work. It is
extremely frustrating that I cannot replicate the problem.
What debugging info can I turn on to distinguish the problem
case from ok case?
I have tried various approaches to fix the problem, even
regularly calling invalidateAllObjects() on the EOEditingContext
but to no avail.
Cheers,
Corin.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
Gordon Belray
Information Architect and Imaging System Manager
Information Technology Services Robarts Library
Gordon Belray
Information Architect and Imaging System Manager
Information Technology Services Robarts Library
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden