Hello!
I think that you need to start a new isolated transaction from callback
(possibly in another thread) to get proper isolation.
Regards,
--
Ilya Kasnacheev
пт, 21 авг. 2020 г. в 18:34, ssansoy <s.san...@cmcmarkets.com>:
> Still seeing the same issue in 2.8.1 unfortunately.
>
> I have a related question however.
>
> Assuming I perform the following operation on node 1 of my 3 node cluster
> (All caches use CacheRebalanceMode.SYNC,
> CacheWriteSynchronizationMode.FULL_SYNC, CacheAtomicityMode.TRANSACTIONAL):
>
>
> try (Transaction tx = ignite.transactions().txStart(
> TransactionConcurrency.PESSIMISTIC,
> TransactionIsolation.READ_COMMITTED,
> transactionTimeout, igniteTransactionBatchSize)) {
>
> // write 1 record to cache A
> // write 11 records to cache B
>
> tx.commit()
>
> }
>
>
> How should I expect the updated A and B records to appear on some other
> node, e.g. node 2.
> I was expecting them to both become visible together at exactly the same
> time. I am using CacheMode.REPLICATED.
>
> On node 2, I am performing a scan query on A, and in the local listen for
> A,
> I am getting those 11 B records (using an SQLFieldsQuery) that were updated
> in the same transaction. However, they don't seem to always be visible
> until
> some time after the local listen for A has been entered. If I put a sleep
> in
> there and try again, I do get all the B's
>
> 2020-08-21 16:25:05,484 [callback-#192] DEBUG x.TableDataSelector [] -
> Executing SQL query SqlFieldsQuery [sql=SELECT * FROM B WHERE A_FK =
> 'TEST4', args=null, collocated=false, timeout=-1, enforceJoinOrder=false,
> distributedJoins=false, replicatedOnly=false, lazy=false, schema=null,
> updateBatchSize=1]
> 2020-08-21 16:25:05,486 [callback-#192] DEBUG x.TableDataSelector [] -
> Received 3 results
> 2020-08-21 16:25:05,486 [callback-#192] DEBUG x.TableDataSelector [] -
> Trying again in 5 seconds
> 2020-08-21 16:25:10,486 [callback-#192] DEBUG x.TableDataSelector [] -
> Received 11 results
>
>
> My local listen for A is annotated with @IgniteAsyncCallback incase that
> matters. Anything obviously wrong here?
> My requirement is that node 2 has access to A and all the updated B's that
> were written on node 1.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>
