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 : Fri Feb 13 2009 - 23:41:12 EST