Hi, I guess 2 scenario behaves considers transactional boundaries because of this feature implemented for DML: https://apacheignite-sql.readme.io/docs/how-ignite-sql-works#section-concurrent-modifications <https://apacheignite-sql.readme.io/docs/how-ignite-sql-works#section-concurrent-modifications>
However, SQL SELECTS are still not transactional. For instance, if you update A and B in one transaction and A has already been updated in the storage while B update is in progress, and at the same time you try to get A and B using SELECT from another transaction then you will see A of the latest version and B of the uncommitted one. That will be solved once we release MVCC. — Denis > On Nov 2, 2017, at 12:21 AM, devkumar <dev...@gmail.com> wrote: > > Hi Denis, > I tested the transactional nature using SqlFieldsQuery and > cache.get()/cache.put() in PESSIMISTIC & REPEATABLE_READ mode. > case 1: update using SqlFieldsQuery in one transaction and read using > SqlFieldsQuery in another transaction on the same record and we didn't > commit any of the transaction. > observation: Lock in write operation and read is not blocked(which > is expected). > case 2: update using SqlFieldsQuery in one transaction and read using > cache.get() in another transaction on the same record and we didn't commit > any of the transaction. > observation: whichever ran first is taking the lock and other one is > blocked > > > Can you please describe transaction nature of SqlFieldsQuery and > cache.get()/cache.put() ? > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/
