Hi Ari,
I tried out a similar approach to yours and it works! I create a new
context whenever it is important to get fresh data, and I do get perfectly
up to date objects. So this solves my conundrum and I can proceed with my
production roll out. Thanks so much.
I'd still be interested to use server-client cache synchronization in the
future, but I think this works fine for my requirements at the moment.
Thanks again
Tarik
On Fri, Feb 13, 2009 at 11:40 PM, Aristedes Maniatis <ar..sh.com.au> wrote:
>
> On 14/02/2009, at 2:04 AM, Tarik Cherkovi wrote:
>
> I did some additional testing today and noticed some patterns:
>> - When I use DataObjectUtils.objectForPK() to find an object, I get a
>> stale
>> version.
>>
>
> Yes, I believe that command always fetches from the local cache, although
> not sure 100%.
>
> - When I run a SelectQuery, I DO get an updated version.
>>
>
> If you aren't using any caching, then yes. [1]
>
> - In all circumstances, 1-many relationships are not updated. The specific
>> issue my users have is one person will add line items to an order (there
>> is
>> a 1-many relationship between order -> lineItem) and nobody else can see
>> the
>> line item added unless they shut down the client and restart it. Same
>> goes
>> for deleting a line item.
>>
>
>
> You need to be aware there are two different caches: a query cache which
> remembers the results of which objects are returned by a certain query, and
> an object cache which keeps a copy of the objects themselves. In the case of
> not seeing new records another client added, the query cache is important to
> you. When following relations, it is as if a query cache is used, even if
> you don't have it switched on. Andrus will be able to explain it better.
>
>
> Each
>> client establishes a channel and creates a context upon login and then
>> re-uses that context throughout the session calling commits and rollbacks,
>> etc, but otherwise, holding on to the same context. Is this the correct
>> design or should I be creating a new context prior to each commit?
>>
>
> That's a perfectly practical approach, but not the one we use in our Swing
> application. We have two types of contexts:
>
> 1. A single read only[2] shared context which is persisted for the life of
> the login and used for all lists, windows, autocomplete areas, etc. We tend
> to fetch in lots of data into this context and refresh it under certain
> circumstances. We switch caching on to make it fast since it typically
> contains quite a lot of data.
>
> 2. Read/write contexts which we create every time a user double clicks on a
> row to edit a record. In our application we open a new editing window, and
> the user could have many open at once. Each has its own context since each
> can be saved independently of the others. These contexts live only for the
> length of time the user has the editing window open, which could be 5
> seconds or 5 hours. Committing the context is always associated with closing
> the window and discarding the context. Cancelling the edit window simply
> discards the context, no rolling back is required.
>
> You need to decide what works for you and the particular user interface
> you've implemented, but this seems to be very effective for us and speed is
> good. Like you, we'd like to implement a notification process to update
> other clients when data is edited, but it hasn't been terribly important for
> us so far given the way we refresh data fairly often and in important
> places.
>
> Ari
>
>
> [1] http://cayenne.apache.org/doc/caching-and-fresh-data.html
> [2] Nothing in Cayenne makes it read only, but we just don't write to it
>
>
>
> -------------------------->
> ish
> http://www.ish.com.au
> Level 1, 30 Wilson Street Newtown 2042 Australia
> phone +61 2 9550 5001 fax +61 2 9550 4001
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
>
>
>
This archive was generated by hypermail 2.0.0 : Sat Feb 14 2009 - 12:02:35 EST