On 14 Mar 2011, at 10:03, Galder Zamarreño wrote:
In fact, if you do what I suggest, you don't need the following:
recoveryInfoCacheName="recoveryCache"
That's optional. If user
doesn't specify that attribute I build a default local cache for him.
Or at least what you could do is this:
- If recoveryInfoCacheName is defined, use that cache configuration after validating that
it fulfills minimum requirements, i.e has passivation enabled...etc.
- If recoveryInfoCacheName not defined, define it programmatically with the correct
expected settings.
That's what I do. The design document reads:
"recoveryInfoCacheName - the name of the LOCAL cache where the recovery information
is stored. If not specified, defaults to a local cache that would expire entries older
than 6 hours."
This way you get best of both worlds. Users are not forced to define the recovery cache,
hence you avoid potential user configuration errors (i.e. forgetting to define the cache
in the first place), while at the same time, people can define the cache to further tweak
it, i.e. tweak lock timeout, expiration time...etc.
This is probably the strategy I should have followed for the Hot Rod topology cache, but
instead went for option that fully hides away the topology cache, and can only be tweaked
via particular parameters.
On Mar 14, 2011, at 10:57 AM, Galder Zamarreño wrote:
> Mircea,
>
> Wrt recoveryCache, do you expect people to define this cache in the XML config? Or
will you build this cache configuration programmatically using defineConfiguration() ?
>
> I think it should be the latter, just like Hot Rod manages the TopologyCache, see:
>
https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma...
>
> Cheers,
>
> On Mar 11, 2011, at 5:43 PM, Mircea Markus wrote:
>
>> Hi,
>>
>> I've updated tx recovery design document[1] after feedback received from
Manik: the most relevant changed is that all recovery information is now stored in a local
cache (user can configure it). This way the user is in control of the memory consumed by
recovery, being able to passivate to disk this information when/if needed. And all this
out-of-the box.
>>
>> Cheers,
>> Mircea
>>
>> [1]
http://community.jboss.org/wiki/Transactionrecoverydesign
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev