[infinispan-dev] (Not-so-)optional cachestores
Tristan Tarrant
ttarrant at redhat.com
Mon Jan 25 08:29:14 EST 2016
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
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
More information about the infinispan-dev
mailing list