cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aristedes Maniatis <>
Subject Re: Commits not visible across contexts in ROP
Date Sat, 14 Feb 2009 04:40:24 GMT

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.


[2] Nothing in Cayenne makes it read only, but we just don't write to it

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

View raw message