Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
- Subject: Re: EOSharedEditingContext and ObjectsChangedInStoreNotification
- From: Dov Rosenberg <email@hidden>
- Date: Tue, 14 Sep 2004 13:12:28 -0400
Are you storing/caching the fetched hotels in App2 into some other data
structure like an NSArray?
Here is the code we use in our application initialization:
...
publisher = new ChangePublisher();
subscriber = new ChangeSubscriber();
ClientSubscriberDelegate subscriberDelegate = new
ClientSubscriberDelegate(config.getServletContext());
subscriber.setChangeDelegate(subscriberDelegate);
subscriber.setEcToUse(EOFactory.editingContext());
...
The EOFactory class simply returns a reference to a regular editing context
(i.e. new EOEditingContext() ) this is the editingcontext that is being
used to do the invalidations
I think we did it that way to give us more flexibility when we deploy as a
servlet (that is how this particular app is deployed)
We use a delegate class (ClientSubscriberDelegate) to perform the actual
custom code we need when something gets invalidated
HTH
Dov
On 9/14/04 12:43 PM, "Hunter Hillegas" <email@hidden> wrote:
> Dov,
>
> The objects are explicitly fetched into a Shared EC using
> bindObjectsWithFetchSpecification().
>
> Basically the flow goes like this:
>
> App 1 starts up.
>
> App 2 starts up. On startup it binds/fetches a list of hotels into the
> default shared editing context.
>
> App 1 fetches a hotel into the session default editing context for a
> user. User makes a change to a text field. Change is saved to the
> database. Your framework sends a JMS message to the JMS topic.
>
> App 2 sees that there was something posted to the JMS topic. It reads
> the change notification and I see that the global ID for the EO has
> been invalidated.
>
> A component is requested by user of App 2. This results in
> objectsByEntityNameAndFetchSpecificationName() being called on the
> default shared editing context and sub-sequently the list of hotels is
> pulled from the shared EC. The hotel in question that was changed is
> displayed in the page and it is displaying the old values.
>
> Based on that scenario, I am pretty sure that the EO should be coming
> from the shared EC... I would have expected
> objectsByEntityNameAndFetchSpecificationName() to notice that the EO's
> globalID was invalidated and have it refault the hotel that had been
> changed...
>
> Am I misunderstanding how this should work?
>
> hunter
>
> On Sep 13, 2004, at 6:46 PM, Dov Rosenberg wrote:
>
>> Hunter,
>>
>> I our code we don't worry about inserts or deletes since most of our
>> application is read only. We created a delegate to implement our update
>> processing. If your shared context is not reflecting the changes, make
>> sure
>> the objects are actually in a shared editing context. I seem to
>> remember
>> somewhere that if an EO is retrieved in a regular editingcontext and is
>> changed EOF won't put the EO in the shared editing context.
>>
>>
>>
>> On 9/13/04 7:49 PM, "Chuck Hill" <email@hidden> wrote:
>>
>>> You could register an object with NSNotificationCenter as an
>>> omniscient
>>> listener and log out all notifications. That might show something.
>>>
>>>
>>> On Sep 13, 2004, at 4:17 PM, Hunter Hillegas wrote:
>>>
>>>> Chuck,
>>>>
>>>> Interesting thought. I looked and it wasn't explicitly set, so I
>>>> modified the code.
>>>>
>>>> Still, App 1 makes a change and App 2 sees it and invalidates the
>>>> GlobalID but the change doesn't show up in the Shared EC.
>>>>
>>>> Do you know of any logging I could turn up to see if the chain is
>>>> broken somewhere inside App 2?
>>>>
>>>> Hunter
>>>>
>>>> On Sep 13, 2004, at 10:51 AM, Chuck Hill wrote:
>>>>
>>>>> One thing that comes to mind is that the framework might not be
>>>>> refetching the objects into an ec with its shared editing context
>>>>> set
>>>>> to null. For details see:
>>>>>
>>>>> http://www.wodev.com/cgi-bin/WebObjects/WODev.woa/wa/Main?
>>>>> wikiPage=HowToUseSharedEditingContexts
>>>>>
>>>>>
>>>>> Chuck
>>>>>
>>>>> On Sep 13, 2004, at 10:34 AM, Hunter Hillegas wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> According to the docs for EOSharedEditingContext, it will listen
>>>>>> for
>>>>>> notifications of the type ObjectsChangedInStoreNotification.
>>>>>>
>>>>>> I am using Dov's JMS change notification framework posted at
>>>>>> WOCode.com - it is based on the code from Wonder with some
>>>>>> important
>>>>>> changes.
>>>>>>
>>>>>> Anyway, the JMS messages are flowing and being processed. When
>>>>>> changes are made in one app, the other app receives the JMS message
>>>>>> and calls invalidateObjectsWithGlobalIDs.
>>>>>>
>>>>>> The thing is, the contents of the EOSharedEditingContext don't
>>>>>> appear to change.
>>>>>>
>>>>>> Subsequent calls to objectsByEntityNameAndFetchSpecificationName()
>>>>>> seem to return the unchanged/original data.
>>>>>>
>>>>>> I was under the impression that invalidateObjectsWithGlobalIDs
>>>>>> would
>>>>>> send a ObjectsChangedInStoreNotification and the Shared EC would do
>>>>>> as the docs state:
>>>>>>
>>>>>> "The shared context removes from its objectsByEntityName and
>>>>>> objectsByEntityNameAndFetchSpecificationName dictionaries any
>>>>>> objects that have been deleted, and it refaults any objects that
>>>>>> have been updated."
>>>>>>
>>>>>> I don't see any evidence of a refault (output is the original
>>>>>> values).
>>>>>>
>>>>>> So... Any ideas on how to troubleshoot this?
>>>>>>
>>>>>> Is there a way to watch/print out
>>>>>> ObjectsChangedInStoreNotifications
>>>>>> as they are dispatched? Is there a way to watch when the shared EC
>>>>>> invalidates/refaults some of its contents?
>>>>>>
>>>>>> Am I mistaken about how this should work?
>>>>>>
>>>>>> Thanks,
>>>>>> Hunter
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>> This email sent to email@hidden
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>> dov.rosenberg@conviveo
>>> n.com
>>>
>>> This email sent to email@hidden
>>
>> --
>> Dov Rosenberg
>> Conviveon Corporation
>> 370 Centerpointe Circle, suite 1178
>> Altamonte Springs, FL 32701
>> http://www.conviveon.com
>> email@hidden
>> AOL IM: dovrosenberg
>> (407) 339-1177 x102
>> (407) 339-6704 (fax)
>> (800) 475-9890
>> (407) 310-8316 (cell)
>>
>
--
Dov Rosenberg
Conviveon Corporation
370 Centerpointe Circle, suite 1178
Altamonte Springs, FL 32701
http://www.conviveon.com
email@hidden
AOL IM: dovrosenberg
(407) 339-1177 x102
(407) 339-6704 (fax)
(800) 475-9890
(407) 310-8316 (cell)
_______________________________________________
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