cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Razumovsky <>
Subject Re: soft or weak
Date Wed, 20 Jan 2010 12:56:03 GMT
Users that need better control over memory, will prefer weak references,
while those that need better control over performance will prefer soft. So
maybe we should have some sort of setting for that (e.g. via IoC)? I'm ok
with soft as default

2010/1/20 Aristedes Maniatis <>

> On 19/01/10 3:34 AM, Andrus Adamchik wrote:
>> Wonder if we should go from WEAK to SOFT as a default policy for object
>> retention in the ObjectStore. I just got a few annoying cases of objects
>> being immediately gc'd after each request, so a new request looking them
>> up by id finds them in the shared cache instead of local (somewhat slow)
>> and then previously resolved to-many relationships are re-read anew
>> (very slow).
>> Of course locally I just switched my ObjectContext factory service to
>> use SOFT, so I am all set (I am yet to see it in production; wonder how
>> that affects already slow major GC cycles). But I am wondering if that
>> would make a better default policy for 3.1?
> It would appear that soft is a better policy, as long as users are
> expecting that their JVM will continue to grow until it uses up all its
> memory. It may lead users to think at first that Cayenne has some sort of
> memory leak.
> I found this interesting article discussing how the gc works with soft
> references:
> Because we could be generating objects very quickly (a big select on the
> database), how the gc does its magic is going to be very important. How will
> it keep up with the memory pressure of creating new objects at a high rate?
> The comments on that page are interesting too: that the soft references are
> not thread safe. Does that affect us?
> And the Google commons code is also interesting, with
> Ari
> --
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message