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 <[email protected]> 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 > > >
