ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From limabean <drobin1...@gmail.com>
Subject How does CacheStore persistence actually work?
Date Tue, 11 Jul 2017 17:46:46 GMT

I saw this remark on the mailing list from vkulichenko:
>> Generally CacheStore is designed to be a single store shared between all
>> nodes. 

I want to develop my own CacheStore implementation to a data store.
The data store will have a "contact point" or client running on each Ignite
node (think a Cassandra node per Ignite node as an example).  I’d like each
Ignite node to “think” that its cache persistence operations are local.

If each ignite node instantiates a copy of my custom CacheStore class on
each node, and each CacheStore instance is configured to talk locally, then
it seems what I describe is possible, but I have many questions. 

Assuming the above is possible:
Each Ignite Node will need the CacheStore classes in its class path.  How do
my custom CacheStore classes get to each node?  How and when are the custom
CacheStore classes distributed to Ignite nodes?  (best practice?)

It does not seem like the cache type (local, replicated or partitioned)
would impact each node writing locally. 
For partitioned caches, that would go through the primary, and for the other
cache types...they are always "primary" ?

None of the examples (in the Ignite code base or documentation) show how to
disconnect an Ignite node from a persistent store in the CacheStore examples
that I have found.  How does this work ? (Not sure how to close the
connection to a database when a CacheStore connection is closed or when an
Ignite BEFORE_NODE_STOP  lifecycle event occurs?)

Thank you,

View this message in context: http://apache-ignite-users.70518.x6.nabble.com/How-does-CacheStore-persistence-actually-work-tp14641.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

View raw message