[infinispan-dev] Integrating Karsten's FCS

Mircea Markus mmarkus at redhat.com
Thu Jul 11 05:53:13 EDT 2013


On 11 Jul 2013, at 10:22, Galder Zamarreño <galder at redhat.com> wrote:

>> | 
>> | Hi,
>> | 
>> | I think we all agree that Karsten's file cache store is a good base
>> | replacement for the current file cache store, particularly for caches with
>> | relatively small keys, or not a huge amount of them.
>> | 
>> | I'm working with Radim to try to figure out what would be the tipping point
>> | at which LevelDB based cache store behaves better compared to Karsten's
>> | cache store.
>> | 
>> | In the mean time, I think we should integrate Karsten's FCS into master and
>> | have it ready for people to try from Alpha1. There's one or two things that
>> | do require a bit of review, but I can pin point them in the pull req.
>> | 
>> | The question is, how should we name it? And what should we do about the
>> | current FCS implementation?
>> | 
>> | Shall we keep the current FCS implementation, deprecate it, and get rid of it
>> | in the next minor/major version? Some users might have data stored in the
>> | current FCS and would be quite abrupt to just get rid of it right now.
>> 
>> I'd remove it in Final, it cannot be seriously used either. Users can migrate the data using rolling upgrades.
> 
> ^ I don't think you can remove it in 6.0 Final. If you wanna do any kind of migration or rolling upgrade from the curren FCS to the new one, you need to have the current FCS around, to be able to read data in that format/setup and then write it to the new cache store. The moment you can remove it is the moment you've decided that no more migrations are gonna happen.

You can have the logic around but don't expose it to the users as a shipped cache store. E.g. move it to a different package and rename it to whatever you want.


Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list