Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (athena.apache.org: domain of mkienenb@gmail.com designates
 74.125.82.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAM1yOja+4CH0CRD45YwQRmGqD0e4knNt0LdCZC5fSLvA_5w8aw@mail.gmail.com>
References: 
 <CAM1yOjbJSWpAVJOF=DHMt0iLQ1_UCtF-Yk=9fMY7ivd5-hwT0Q@mail.gmail.com>
 <5E9091FB-D5B5-47FC-958E-744F41177D8D@objectstyle.org>
 <CAM1yOja+4CH0CRD45YwQRmGqD0e4knNt0LdCZC5fSLvA_5w8aw@mail.gmail.com>
From: Mike Kienenberger <mkienenb@gmail.com>
Date: Fri, 27 Sep 2013 15:32:19 -0400
Message-ID: 
 <CAM1yOjbSRz9VTacrB0jAj2auPVj+Z3btjzpXZzqu+bYx21+RcA@mail.gmail.com>
Subject: Re: 3.0 -> 3.1: Committed changes not propagating to other contexts /
 invalidating objects not removing cached values
To: user@cayenne.apache.org
Content-Type: text/plain; charset=ISO-8859-1

This is probably the biggest unresolved issue still facing me, at
least of those I know about.   Is one of the 3rd party packages
required to make invalidateObjects() work?   If not, what should I be
using in my configuration to replace the default JavaGroups event
bridge?

On Tue, Sep 24, 2013 at 9:50 AM, Mike Kienenberger <mkienenb@gmail.com> wrote:
> On Tue, Sep 24, 2013 at 2:15 AM, Andrus Adamchik <andrus@objectstyle.org> wrote:
>> Could be because peer context notifications are now asynchronous and you test runs before the change is propagated? Async context synchronization is used for performance reasons and to avoid deadlocks.
>
> That was one of my first thoughts, so first I set a breakpoint to
> insure there was enough time to propagate the changes.   Then I traced
> through the event notification and found that nothing was registered
> to listening for the events.
>
>
>>> It does look like JavaGroupsBridgeFactory gets instantiated as the
>>> default event bridge factory, although if I don't have it installed
>>> (which I don't) it's replaced by a noop event manager.
>>
>> That'll be odd. Has to be something in configs.
>
> The source code indicates that JavaGroups is the default.
>
>     public static final String EVENT_BRIDGE_FACTORY_DEFAULT =
> "org.apache.cayenne.event.JavaGroupsBridgeFactory";
>
> So, what should I be looking for?   I have no event bridge factory
> configured in the cayenne*.xml file.   This seems to match the
> tutorial projects as well as a new empty project I set up.
> Furthermore, I see no EventBridgeFactory implementations other than
> JavaGroups, JMS, and XMPP bridge factory implementations in the 3.1
> source, all of which require third-party libraries.
>
> Is a 3rd-party package required for this to work as advertised?
>
>
>
>> On Sep 23, 2013, at 11:10 PM, Mike Kienenberger <mkienenb@gmail.com> wrote:
>>
>>> Under 3.0.2, I have a test that creates a local copy of an object in a
>>> new DataContext, makes a change to it, commits the change, and then
>>> verifies that both the old copy and the new copy match.   And this
>>> passes.
>>>
>>> Under 3.1, the old object does not reflect the new changes, although
>>> the 3.x docs state that it should by default:
>>>
>>> http://cayenne.apache.org/docs/3.1/cayenne-guide/performance-tuning.html#caching-and-fresh-data
>>>
>>> This appears to be because there's nothing listening for the
>>> postSnapshotsChangeEvent, maybe because there's an error in my
>>> hand-converted modeler test configuration file.
>>>
>>> It does look like JavaGroupsBridgeFactory gets instantiated as the
>>> default event bridge factory, although if I don't have it installed
>>> (which I don't) it's replaced by a noop event manager.
>>>
>>> Ebpp DEBUG [main 09-23 15:42:44] DataRowStore: DataRowStore property
>>> cayenne.DataRowStore.snapshot.expiration = 7200
>>> Ebpp DEBUG [main 09-23 15:42:44] DataRowStore: DataRowStore property
>>> cayenne.DataRowStore.snapshot.size = 10000
>>> Ebpp DEBUG [main 09-23 15:42:44] DataRowStore: DataRowStore property
>>> cayenne.DataRowStore.remote.notify = false
>>> Ebpp DEBUG [main 09-23 15:42:44] DataRowStore: DataRowStore property
>>> cayenne.DataRowStore.EventBridge.factory =
>>> org.apache.cayenne.event.JavaGroupsBridgeFactory
>>>
>>>
>>> So I decided to see whether I could force a refetch for the existing
>>> object in the original database using:
>>>
>>>        context.invalidateObjects(this);
>>>        context.prepareForAccess(this, null, false);
>>>
>>> prepareForAccess is pulling the old value out of the cachedSnapshots.
>>> This is rather unexpected since invalidateObjects() claims clears out
>>> the cache.    All I see it doing when I step through the values is
>>> resetting the persistence state from committed to hollow.    I don't
>>> see anything in stepping through the code which would remove the cache
>>> snapshot for the data context as documented.
>>>
>>>    /**
>>>     * Invalidates a Collection of persistent objects. This operation
>>> only applies to the
>>>     * objects already committed to the database and does nothing to
>>> the NEW objects. It
>>>     * would remove each object's snapshot from caches and change
>>> object's state to
>>>     * HOLLOW. On the next access to this object, the object will be refetched.
>>>     */
>>>    void invalidateObjects(Collection<?> objects);
>>>
>>>
>>> If I manually remove the item from the cache, then it works, even
>>> without prepareForAccess().
>>>
>>>        ObjectContext context = getObjectContext();
>>>        DataContext dataContext = (DataContext)context;
>>>        dataContext.getObjectStore().getDataRowCache().forgetSnapshot(this.getObjectId());
>>>        context.invalidateObjects(this);
>>>
>>> It seems to me that it's a bug to not invalidate the DataContext
>>> DataRowCache snapshot during invalidateObjects().
>>>
>>