[infinispan-dev] Shared vs Non-Shared CacheStores

Tristan Tarrant ttarrant at redhat.com
Thu Aug 6 04:31:18 EDT 2015


On 05/08/2015 23:57, Sanne Grinovero wrote:
> For example it seems Bela will soon allow more flexibility in JGroups
> regarding buffer representations. We need to commit on a stable API
> for end user integrations (shared cachestore implementors), but we
> also need to keep options open to soon play with other approaches.
>
> That's why I think this separation should be done before Infinispan
> 8.0.0.Final even if I don't have a concrete proposal for how this

If we don't have a concrete proposal by the end of this week, I think we 
should forgo this until Infinispan 9 and until we've clearly defined 
what we need/want.
I am pretty annoyed, and I'm certain our users even more so, by the SPI 
and configuration changes that have happened over all of our major 
versions and I don't want to inflict that pain again, even though we 
might reap some benefits by redesigning (yet again) the store SPI.
The solution I would like to see would be some backward- and forward- 
compatible way of a store exposing the "capabilities" it supports (e.g. 
SHARED, TRANSACTIONAL, etc) so that the PersistenceManager deals with 
them accordingly.

Tristan
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat


More information about the infinispan-dev mailing list