cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Scale out
Date Thu, 30 May 2013 06:33:59 GMT
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 ;)


On May 30, 2013, at 5:02 AM, Malcolm Edgar <> 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 <>wrote:
>> 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 <>
>> 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]
>>> --
>>> -------------------------->
>>> Aristedes Maniatis
>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A

View raw message