Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <447724DF.3040308@spree.de>
Date: Fri, 26 May 2006 17:55:11 +0200
From: Michael Bouschen <mbo.tech@spree.de>
Organization: Tech@Spree Engineering
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: jdo-dev@db.apache.org
Subject: Re: huge volumes and flush
References: <1148480487.44746be776fcd@webmail.jpox.org>
 <8E1F6DAE-1063-4FD1-9329-4C2F34A6314E@SUN.com>
 <1148635580.4476c9bca970a@webmail.jpox.org>
In-Reply-To: <1148635580.4476c9bca970a@webmail.jpox.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Erik,

most probably you know already: class WeakHashMap from java.util does 
not help when implementing the map of flushed instances. The WeakHashMap 
uses a WeakReference for the key, but it strongly references the value 
which is the flushed instance in your case. You need a map 
implementation that maintains a strong reference to the key, but a weak 
reference to the value. Just in case you are interested: there is a 
tested implementation in the core20 module of the apache jdo repository. 
The class is called WeakValueHashMap and you find it under 
core20/src/java/org/apache/jdo/util.

Regards Michael
> Thanks Craig,
>
> I works now.
>
> Quoting Craig L Russell <Craig.Russell@Sun.COM>:
>
>   
>> Hi Erik,
>>
>> Generally, use weak references to persistent instances so they can be
>> garbage collected when the user no longer holds a strong reference to
>> them. Unflushed dirty instances need to be referenced strongly so
>> they are not garbage collected. So at flush time, move the flushed
>> dirty instances from a strong-reference map to a weak-reference map
>> (key = oid, value = weak-reference object).
>>
>> Craig
>>
>> On May 24, 2006, at 7:21 AM, Erik Bengtson wrote:
>>
>>     
>>> Hi,
>>>
>>> In case of huge amount of objects loaded /persisted, the flush
>>> method is for
>>> this purpose. I wonder how the cache/state management can be
>>> implemented
>>> without breaking JDO contract and capable to handle load, any tips?
>>>
>>> Thanks
>>>
>>> Erik Bengtson
>>>       
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>>     
>
>
>   


-- 
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66			
Fax.:++49/30/2175 2012		D-10783 Berlin