Re: Scale out

[Andrus Adamchik]

I second all the suggestions here. My rules of thumb are:

* Don't try to sync individual objects. You can't cluster that well (whatever 
Terracotta might claim, there are issues beyond transferring object state).
* Turn off object cache syncing completely, even within a single VM, to get 
consistent behavior across the cluster.
* Use query cache. It can be clustered very efficiently.
* Setup lifecycle events to kick certain cache groups when certain objects are 
modified
* Consider optimistic locking

BTW I will be discussing caching in great detail at WOWODC Cayenne Training Day 
in Montreal this summer ;)
 
http://www.wocommunity.org/wowodc13/cayenne.html

Andrus

On May 30, 2013, at 5:02 AM, Malcolm Edgar malcolm.ed...@gmail.com wrote:

 I have found using Caching Groups with relatively short timeouts 15
 seconds, can have a huge performance benefit while still keeping most data
 quite fresh.
 
 
 On Thu, May 30, 2013 at 11:21 AM, Mike Kienenberger mkien...@gmail.comwrote:
 
 And be careful not to overdo it.   I made that mistake in my first
 ecommerce app.
 
 In hindsight, it was sufficient to make sure the data was refreshed at
 the beginning of each request, rather than as soon as possible.
 
 
 On Wed, May 29, 2013 at 7:39 PM, Aristedes Maniatis a...@maniatis.org
 wrote:
 On 29/05/13 8:14pm, Christian Grobmeier wrote:
 
 My concern is the Cayenne caching mostly. What if
 App1 is doing an update and the next requests select from App2?
 
 
 No one can answer this other than you. What does happen?
 
 Are you writing an ecommerce system where data has to be fresh to the
 millisecond? Or does data need to be consistent per user/session? If the
 latter, sticky sessions will help you. If the former, you may need to
 remove
 the cache entirely or use a distributed cache like Terracotta [1]
 
 From my own experience with distributed caching, it can get very
 complicated
 very quickly. Luckily we were able to avoid all caching in the critical
 parts of the application, and plenty of non-distributed caching in the
 other
 parts where performance was critical but 20 minutes of staleness was OK.
 
 Ari
 
 
 [1]
 
 http://www.ehcache.org/documentation/2.4/terracotta/distributed-caching-with-terracotta
 
 --
 --
 Aristedes Maniatis
 GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
 

Re: Scale out

[Aristedes Maniatis]

On 30/05/13 4:33pm, Andrus Adamchik wrote:

* Don't try to sync individual objects. You can't cluster that well (whatever 
Terracotta might claim, there are issues beyond transferring object state).


Yes, and one more thing to think about: what happens when you upgrade an 
instance on your cluster to a new version of the application. You'll end up 
with serialisation errors for objects which are different versions as they are 
synced between instances. So you will need to end up with at least two groups 
of clusters, each with their own backing cache, and upgrade each group as a set.

This is the same problem as having distributed sessions (rather than sticky 
sessions) and I've not ever found a good solution for it. But with a 
distributed cache the problem is even worse.


Ari


--
--
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A