Continuous query not transactional ?

[VeenaMithare]

Hello team,

This is in continuation to these posts on the ignite users

http://apache-ignite-users.70518.x6.nabble.com/Continuous-query-not-transactional-td34270.html
and
http://apache-ignite-users.70518.x6.nabble.com/Lag-before-records-are-visible-after-transaction-commit-tp33787p33861.html

Does this mean we could get dirty reads as updates in continuous query ?
i.e. for eg if the code is as below:
1. Start transaction  
2. update records of cache a
3. update records of cache b
4. update records for cache c
5. commit

if update of cache a succeeds , but update of cache b fails, will the local
listener for continuous query for 'cache a' get an update ?

regards,
Veena.





--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[Ivan Pavlukhin]

Hi Veena,

As far as I know, CQ listeners should not be notified about
non-committed writes. I suppose that it is possible to reproduce a
described scenario, what does it show in practice?

Also it is important to know that all participating caches should be
TRANSACTIONAL and "update of cache b fails" possibly does not mean
that a transaction is rolled back.

2020-10-17 14:28 GMT+03:00, VeenaMithare <[hidden email]>:

> Hello team,
>
> This is in continuation to these posts on the ignite users
>
> http://apache-ignite-users.70518.x6.nabble.com/Continuous-query-not-transactional-td34270.html
> and
> http://apache-ignite-users.70518.x6.nabble.com/Lag-before-records-are-visible-after-transaction-commit-tp33787p33861.html
>
> Does this mean we could get dirty reads as updates in continuous query ?
> i.e. for eg if the code is as below:
> 1. Start transaction
> 2. update records of cache a
> 3. update records of cache b
> 4. update records for cache c
> 5. commit
>
> if update of cache a succeeds , but update of cache b fails, will the local
> listener for continuous query for 'cache a' get an update ?
>
> regards,
> Veena.
>
>
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

--

Best regards,
Ivan Pavlukhin