[infinispan-dev] (Not-so-)optional cachestores

Radim Vansa rvansa at redhat.com
Mon Jan 25 09:39:25 EST 2016


Would the deployable cache stores benefit from 4) as well? It seems to 
me as the only 'right' option.

R.

On 01/25/2016 02:29 PM, Tristan Tarrant wrote:
> Hi all,
>
> Jakub has recently revived the Cassandra Cache Store (CCS from now on)
> which, as you all will remember, was pushed to an external repository
> where it lay in abandonment ever since.
>
> We now need to add support for this store to Infinispan Server, but
> unfortunately, because of the "monolithic schema" approach that WildFly
> imposes on subsystems, this has to be done within the Infinispan
> subsystem itself.
> This creates a conundrum, since the CCS depends on Infinispan core,
> server would depend on the CCS but server is part of the Infinispan build.
>
> Possible solutions:
> 1) move the CCS back into the main repo
>      - pros: no more conundrum, built by default, easier to maintain
>      - cons: makes the repo even bigger, binds the lifecycle of the CCS
> to Infinispan's
> 2) extend the server to be able to interpret the CCS schema but not
> actually depend on its code and provide the code to instantiate the CCS
> as an overlay module which can be installed on server
>      - pros: keeps the lifecycle of the CCS independent
>      - cons: additional complexity to handle the split, forces us to
> still keep server aligned with schema changes in the CCS itself.
> 3) make the CCS a deployable cache store
>      - pros: easiest
>      - cons: not really ootb experience, no nice schema
> 4) create a dedicated subsystem for the CCS and "invent" a way to
> reference it from the main Infinispan subsystem using a naming
> convention, similar to how datasources are currently implemented.
>      - pros: keeps the two projects independent, reusable for other
> Cachestores
>      - cons: writing a subsystem from scratch is complex (although bits
> of it could be made reusable for multiple cachestores).
>
> Your thoughts please.
>
> Tristan


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team



More information about the infinispan-dev mailing list