Re: JDBC Thin Client with Transactions

[vkulichenko]

If client node based driver [1] is used, then you can also add
transactionsAllowed=true parameter to URL to overcome this error.

This will NOT enable transactional support, but will force the driver to go
through transaction related methods without exceptions. So for example, if
there are several updates executed in a transaction, they will be actually
executed as individual updates.

Obviously this option should be used with care, and most likely not in
production environments. But if you're testing integration of Ignite with
some external tools, it can be useful until full transactional support is
available.

[1] https://apacheignite-sql.readme.io/docs/jdbc-client-driver

-Val



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: JDBC Thin Client with Transactions

[Denis Magda]

Hi,

The transactional SQL should be rolled out in Q2 this year.

"java.sql.SQLFeatureNotSupportedException: Transactions are not supported” 
exception is caused by this missing piece, yes. You can’t execute INSERTS, 
UPDATES, DELETES, MERGE queries inside of Ignite transactions.

However, you can run individual INSERTS, UPDATES, etc. for sure.

—
Denis

> On Jan 4, 2018, at 8:55 PM, Teki  wrote:
> 
> Hi Denis,
> 
> When this feature will be available? Is this why I am getting the error
> mentioned in the below post?
> Please assist. Thanks in advance !!
> 
> http://apache-ignite-users.70518.x6.nabble.com/insert-into-ignite-cache-from-Netezza-database-using-talend-tp19295.html
> 
> 
> 
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: JDBC Thin Client with Transactions

[Teki]

Hi Denis,

When this feature will be available? Is this why I am getting the error
mentioned in the below post?
Please assist. Thanks in advance !!

http://apache-ignite-users.70518.x6.nabble.com/insert-into-ignite-cache-from-Netezza-database-using-talend-tp19295.html



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: JDBC Thin Client with Transactions

[Denis Magda]

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
 


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  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/

Re: JDBC Thin Client with Transactions

[devkumar]

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

[Denis Magda]

On Monday, October 30, 2017, iostream  wrote:

> So the transactional guarantees apply only to cache.get() and cache.put()
> category of APIs?
>
> Yes


> What about SqlFieldsQuery? Does it also support transactional
> commits/rollbacks?
>
>
SQL fields queries fall in the same category of presently non transactional
APIs.

Denis

>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: JDBC Thin Client with Transactions

[iostream]

So the transactional guarantees apply only to cache.get() and cache.put()
category of APIs? 

What about SqlFieldsQuery? Does it also support transactional
commits/rollbacks?



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: JDBC Thin Client with Transactions

[Denis Magda]

No, you need to wait for the feature release. Should be the beginning of
the next year.

For now I can suggest using fully transactional key-value APIs for those
operations that require transactional guarantees and stay with DML for the
rest.

Denis

On Saturday, October 28, 2017, iostream  wrote:

> Found a ticket for this feature. Are there alternate ways to achieve
> TRANSACTIONAL sql using JDBC Thin Driver?
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: JDBC Thin Client with Transactions

[iostream]

Found a ticket for this feature. Are there alternate ways to achieve
TRANSACTIONAL sql using JDBC Thin Driver? 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/