[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