You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by devkumar <de...@gmail.com> on 2017/11/02 07:21:43 UTC
Re: JDBC Thin Client with Transactions
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/
Re: JDBC Thin Client with Transactions
Posted by Denis Magda <dm...@apache.org>.
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 <de...@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/