Hi Arial, >> But there are also non-transactional reads from one of the caches. Any operation on a transaction cache executes within a transaction. If the transaction isn't declared, it is created implicitly with default concurrency and isolation modes.
>> There will be only 2PC commit for transactions, no 1-phase commit, since I >> have 3 nodes, REPLICATED? Yes 2PC commit will be used. >>During the transaction, even for get, locks will be taken on backups >>during the prepare phase, since it's PESSIMISTIC concurrency? Locks will be taken during a transaction before read/write operations. >> readFromBackup - looks like it's not going to improve transactions >> performance since transaction coordinator still going to always send it to >> primary node and primary node will instruct backup to take locks? >>* readFromBackup - still should help in non-transactional read, no? or it >>always sent to primary node? readFromBackup enhances performance for cache operations. Locking and performance depend on the type of cache operation read or write, concurrency and isolation levels. Better performance could be achieved by using deadlock free optimistic/serializable transactions. >>* affinity - will it help to configure it for REPLICATED caches, where >>transaction touches all the node anyway? I suppose that affinity doesn't affect to transaction performance. >>* If there is no timeout for transaction and one of the backup nodes is >>segmented out, transaction seems to be blocked for FailureDetectionTimeout >>time (worst case). But is it supposed to resume and succeed after topology >>is recalculated to include 2 nodes only? Yes transaction resumes after topology is recalculated. 2018-04-06 3:14 GMT+03:00 Ariel Tubaltsev <[email protected]>: > I have 2 different caches C1, C2 on 3 nodes N1, N2, N3. I want to configure > it in the most possibly reliable way to avoid any inconsistency and data > loss, so both caches are REPLICATED, TRANSACTIONAL, FULL_SYNC. > > Most of my operations are transactions: PESSIMISTIC, SERIALIZABLE that > touch > both caches, for example > tx { > v= get(C1, k1); > put(C2, v, x); > } > > But there are also non-transactional reads from one of the caches. > All operations are performed from client (in client mode). > > Some questions to better map the features: > > * There will be only 2PC commit for transactions, no 1-phase commit, since > I > have 3 nodes, REPLICATED? > * During the transaction, even for get, locks will be taken on backups > during the prepare phase, since it's PESSIMISTIC concurrency? > * readFromBackup - looks like it's not going to improve transactions > performance since transaction coordinator still going to always send it to > primary node and primary node will instruct backup to take locks? > * readFromBackup - still should help in non-transactional read, no? or it > always sent to primary node? > * affinity - will it help to configure it for REPLICATED caches, where > transaction touches all the node anyway? > * If there is no timeout for transaction and one of the backup nodes is > segmented out, transaction seems to be blocked for FailureDetectionTimeout > time (worst case). But is it supposed to resume and succeed after topology > is recalculated to include 2 nodes only? > > Thank you > Ariel > > > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ > -- Regards Pavel Vinokurov
