Hi Denis/Igor, I can confirm that I've managed to get this working :)
I've got a C++ program running just fine. It uses Ignite C++ with a CacheStoreAdapter-derived Java class that implements persistent storage (MongoDB in this case, but easily replaceable). Thanks for your help, Graham On 6 June 2016 at 08:37, Graham Bull <kaiz...@gmail.com> wrote: > Hi Denis/Igor, many thanks for the info, I'll give this a try. > > Graham > > > On 3 June 2016 at 16:34, Igor Sapego <isap...@gridgain.com> wrote: > >> Hi Guys, >> >> As far as I understand, yes, this is going to work as long as all >> necessary user Java classes are available for the C++ node. >> >> Best Regards, >> Igor >> >> On Fri, Jun 3, 2016 at 3:53 PM, Denis Magda <dma...@gridgain.com> wrote: >> >>> Hi Graham, >>> >>> You can specify a Java-based implementation of a persistent storage in >>> Spring XML configuration of Ignite and start a C++ node with this >>> configuration. After that the data that is stored on C++ node should be >>> persisted as well. >>> >>> *Igor Sapego*, please correct me if I’m wrong. >>> >>> — >>> Denis >>> >>> On Jun 2, 2016, at 1:38 PM, Graham Bull <kaiz...@gmail.com> wrote: >>> >>> We'd like to use Ignite with persistent storage. However, I'm not sure >>> if our scenario is feasible. >>> >>> We'll be using Ignite C++. From the documentation it seems as though >>> this provides a limited subset of the full Java version. There's no compute >>> functionality, but that's coming soon. But more importantly (for us) >>> there's no persistent storage functionality. >>> >>> I understand that Ignite C++ can cluster with Ignite Java. If that's >>> indeed the case, and the Java instances are able to persist the data they >>> contain, then what happens to the data on the C++ instances? Will it be >>> persisted, or will it be lost when the C++ instances are shut down? >>> >>> The thinking was that initially we'd have a cluster consisting of one >>> C++ instance and one or more Java instances. And later on, once compute >>> functionality is available, we'd move everything to C++. >>> >>> Thanks in advance, >>> >>> Graham >>> >>> >>> >> >
