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: local policy)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: Peer Context Synchronization
From: Andrus Adamchik <andrus@objectstyle.org>
In-Reply-To: 
 <CALAw18yzaz+c9c8LUqX2coBBcOrM3hLLzP7VLxetdMiCMasU_A@mail.gmail.com>
Date: Wed, 24 Apr 2013 14:51:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC36FCC0-4BA8-4782-B1E3-83531933E4ED@objectstyle.org>
References: 
 <CALAw18yydt+PvEBJb+66RCS92wgMaSe_LWe4Xn8JW47Cha0o_w@mail.gmail.com>
 <523B0521-6A9B-48E2-AD1D-EAAE2F14A825@objectstyle.org>
 <CALAw18yzaz+c9c8LUqX2coBBcOrM3hLLzP7VLxetdMiCMasU_A@mail.gmail.com>
To: user@cayenne.apache.org

Yes, performance implications are pretty serious. To a point that in my =
webapps I am completely turning off cross-context syncing via a DI =
property, as even async process is O(N) as far as resource consumption, =
and in an app with a large number of active contexts things are going to =
get bad pretty quickly.

There are a few ways you can deal with it:

1. You can listen for DataChannel.GRAPH_CHANGED_SUBJECT subject for a =
given context (or all contexts at once, if that makes sense in your app) =
:

// here is how you access EventManager to register listeners:
EventManager em =3D runtime.getChannel().getEventManager();

// register listener
em.addListener(listener, "xyzMethod", GraphEvent.class, =
DataChannel.GRAPH_CHANGED_SUBJECT, myContext);

2. You can override ObjectStoreFactory in DI to implement synchronous =
events (isn't it cool to have a DI-based framework :))=20

// implement the factory=20
public class MyObjectStoreFactory implements ObjectStoreFactory {
 // check DefaultObjectStoreFactory for details, create a sublcass of =
ObjectStore,=20
 // overriding 'setDataRowCache'
}

// bind it in a custom module:
binder.bind(ObjectStoreFactory.class).toIn(MyObjectStoreFactory.class);

Andrus


On Apr 24, 2013, at 2:34 PM, Lon Varscsak <lon.varscsak@gmail.com> =
wrote:
> Is there any way to control that behavior?  Like is there a way for my =
code
> to wait for that to complete?  I understand the performance =
considerations,
> but it's a fairly common pattern for me (from the WO/EOF space) to =
expect
> this to be done before any more of my code gets executed.
>=20
> Thanks,
>=20
> Lon
>=20
>=20
> On Wed, Apr 24, 2013 at 11:26 AM, Andrus Adamchik =
<andrus@objectstyle.org>wrote:
>=20
>> Hi Lon,
>>=20
>> Context update is immediate, but asynchronous, so this likely =
explains the
>> observed behavior.
>>=20
>> Andrus
>>=20
>> On Apr 24, 2013, at 2:14 PM, Lon Varscsak <lon.varscsak@gmail.com> =
wrote:
>>> Hey all, I'm having some trouble with something that I _think_ =
should
>> work.
>>> :)
>>>=20
>>> It's a very common pattern for me to create a new context, do work, =
save,
>>> and expect those changes to make it back into peer contexts that =
share
>>> object ids.
>>>=20
>>> However, there are times where this isn't happening=85and it's
>> intermittent.
>>>=20
>>> My model in this situation is pretty simple, there's EntityA with a
>> to-many
>>> to EntityB.  In a peer context, I'm creating an EntityB and adding =
it to
>>> the relationship of EntityA (a local instance), and generally =
speaking,
>> in
>>> my other peer context the matching instance of EntityA is updated =
and has
>>> the proper EntityB in it's relationship (after commitChanges).
>>>=20
>>> However, occasionally=85maybe 1 in 10, the peer context doesn't get
>>> immediately updated (although will, I believe, at a later time).
>>>=20
>>> So the question is, does commitChanges immediately/synchronously =
push all
>>> changes into peer contexts?  Or does it happen in another way?
>>>=20
>>> Thanks for any insight.
>>>=20
>>> -Lon
>>=20
>>=20