hmm. Cache not updating on many to one updates unless parent explicitly
discarded.

:( Back to testing.

- Gabriel

On Wed, Jan 20, 2010 at 5:15 PM, Dorioo <[email protected]> wrote:

> A. Yup, that's what I'm referring to. :-) I don't want to be responsible
> for calling shutdown().
>
> What was bothering me is the case where say, you're reinitlizating your
> app, transfer gets loaded, and a bad error happens that stops the
> initialization process midway. You're then left with an instance of ehcache
> and no way to shut it down.
>
> Granted this should be an edge exception in production but led me to this
> experiment.
>
> B. Attached is what I have so far. It's all cache and no statistics but
> maybe others will find it useful.
>
>    1. The CF9 object cache is _not_ exclusive to this provider so I didn't
>    incorporate any settings for the cache. Those should be set elsewhere in
>    your app using CacheSetProperties()
>    2. Currently extends "transfer.com.cache.provider.AbstractBaseProvider"
>    so it's assuming you have a "/transfer" mapping. Change as needed
>    3. ShutDown() simulates the existing ehCache implementation by
>    discarding all related objects. However, if this call were to fail or never
>    be called, the object themselves timeout and so they'll eventually be 
> purged
>    regardless of whether shutdown() fails or is never called.
>    4. Usage example below where timeSpan and idleTime are minutes,
>    required, and are explained in the CF9's CachePut() function.
>
> <defaultcache provider="transfer.path.to.this.file.antCF9CacheProvider">
>      <setting name="timeSpan" value="30"/>
>      <setting name="idleTime" value="15"/>
> </defaultcache>
>
> - Gabriel
>
> On Wed, Jan 20, 2010 at 4:12 PM, Mark Mandel <[email protected]>wrote:
>
>> On Thu, Jan 21, 2010 at 2:34 AM, Dorioo <[email protected]> wrote:
>>
>>> Main benefit I was looking for is not having to manage the ehCache
>>> instance myself.
>>
>>
>> You know the eHCache provider in Transfer manages this for you? You just
>> call .shutdown() on transfer, and the ehCache Cache is shutdown properly. No
>> more management than that necessary.
>>
>>
>>> If I fail to properly shutdown an ehcache instance, it remains in memory.
>>> Using the CF9 object cache, I simulate a "shutdown" by discarding all of the
>>> objects in the CF9 object cache that begin with my providers naming prefix.
>>> And if that were to fail for any reason, the objects themselves have a
>>> timeout and would be purged in time anyway by CF9.
>>>
>>> Obvious limitations are with the limited ways in which CF9 allows you to
>>> interact with its object cache but so far it's looking viable for my needs.
>>>
>>
>> When you get it finished, feel free to post it to the list, and I can add
>> it as a cache provider in Transfer.
>>
>> Mark
>>
>> --
>> E: [email protected]
>> T: http://www.twitter.com/neurotic
>> W: www.compoundtheory.com
>>
>> Hands-on ColdFusion ORM Training @ cf.Objective() 2010
>> www.ColdFusionOrmTraining.com/
>>
>> --
>> Before posting questions to the group please read:
>>
>> http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer
>>
>> You received this message because you are subscribed to the Google Groups
>> "transfer-dev" group.
>> To post to this group, send email to [email protected]
>> To unsubscribe from this group, send email to
>> [email protected]
>> For more options, visit this group at
>> http://groups.google.com/group/transfer-dev?hl=en
>>
>
>

-- 
Before posting questions to the group please read:
http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer

You received this message because you are subscribed to the Google Groups 
"transfer-dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/transfer-dev?hl=en

Reply via email to