Hi Igor, In a multi-cache transaction there can several different stores involved, that's why store is not considered to be self-contained. That's why transaction callbacks moved to a separate entity - store session listener.
Can you please clarify how do you suggest to use Transaction for this? This interface is not implemented by a user, so it's not clear to me. -Val On Fri, Jul 29, 2016 at 6:40 PM, Igor Rudyak <irud...@gmail.com> wrote: > Hi guys, > > Playing with Ignite multi-cache transactions(transactions involving > multiple caches) we run into the lack of proper/easy mechanism to support > such transactions on persistent store side (while implementing particular > *CacheStore*). > > The problem is there is no easy way for *CacheStore *implementation to get > information about caches involved in the transaction. > > Here are more details: > > When committing multi-cache transaction, Ignite produces multiple > *sessionEnd(...)* calls (in *CacheStore *implementation) - one for each > cache. Thus to support multi-cache transaction in persistent store, we need > to accumulate all the changes made to multiple caches (by > *write/writeAll/delete/deleteAll* operations) and apply them as one > transaction/batch to a persistent store in the final(last) *sessionEnd > *call. > To do this we need to know exact number of caches participating in the > transaction. Having this number we can skip all *sessionEnd *calls except > the last - which we will use to commit/persist all the changes we > previously accumulated. > > As for now, the only way to get the number of caches participating in a > transaction is to register *CacheStoreSessionListener *and count number of > caches in its "*onSessionStart*" method. Such approach doesn't look very > elegant cause we always need to keep in mind that specifying " > *cacheStoreFactory*" in cache configuration is not enough. In addition to > this we also need to specify appropriate " > *cacheStoreSessionListenerFactories*" property - otherwise it will not work > for multi-cache transactions. > > Here is an example chunk from cache configuration: > > * <property name="cacheStoreFactory">* > * <bean > > class="org.apache.ignite.cache.store.cassandra.CassandraCacheStoreFactory">* > * <property name="dataSourceBean" value="cassandraDataSource"/>* > * <property name="persistenceSettingsBean" > value="cache1_persistence_settings"/>* > * </bean>* > * </property>* > * <property name="cacheStoreSessionListenerFactories">* > * <list>* > * <bean class="org.apache.ignite.tests.MyCacheStoreSessionListener"/>* > * </list>* > * </property>* > > We see that, instead of specifying only one property "*cacheStoreFactory*" > for a cache we should always specify two properties in case we need > multi-cache transactions support in persistent store. Conceptually it > doesn't look good, cause users thinking about *CacheStore *implementation > like something self-contained - once it specified in cache configuration > everything should be smooth. But in case of multi-cache transactions > support we always need to remember about registering some strange > "listener". > > In Ignite we already have such concept as " > *org.apache.ignite.transactions.Transaction*" which defines our > transaction. It looks logical if it will also provide information about > transaction boundaries (caches involved into transaction). Such approach > can simplify persistent store implementation for multi-cache transactions. > > Any thoughts? > > > Igor Rudyak >
