Re: TX savepoints

Agree. On Tue, Nov 8, 2016 at 12:38 PM, Sergi Vladykin wrote: > > > > I see your point, but why not add the SQL commands right now and support > > transactions in the same way we support them in the project? > > > > It means that we will support TXs only for direct SQL mappings for cache > comma

Re: TX savepoints

> > I see your point, but why not add the SQL commands right now and support > transactions in the same way we support them in the project? > It means that we will support TXs only for direct SQL mappings for cache commands: INSERT (putIfAbsent), MERGE by primary key (put) and DELETE by primary ke

Re: TX savepoints

On Tue, Nov 8, 2016 at 11:51 AM, Sergi Vladykin wrote: > Dmitriy, > > I don't see how we can support it without having all the complex MVCC > machinery that we are creating for 2.0 (and it is very far from being > ready). > I see your point, but why not add the SQL commands right now and support

Re: TX savepoints

Created tickets for transactional support of DML and SELECT statements on JDBC, ODBC and DML API sides https://issues.apache.org/jira/browse/IGNITE-4191 The parent ticket depends on MVCC. — Denis > On Nov 8, 2016, at 11:51 AM, Sergi Vladykin

Re: TX savepoints

Dmitriy, I don't see how we can support it without having all the complex MVCC machinery that we are creating for 2.0 (and it is very far from being ready). Sergi 2016-11-08 20:38 GMT+03:00 Dmitriy Setrakyan : > I am not sure why we don't add the transaction support now, given that we > are goi

Re: TX savepoints

I’ve wrapped up the outcomes of the discussion and created JIRA tickets https://issues.apache.org/jira/browse/IGNITE-4188 Sergi, do we already have a ticket created for >> All the SQL statements currently run out of transactions. It is a big >

Re: TX savepoints

I am not sure why we don't add the transaction support now, given that we are going to support insert, update, and delete statements. On Tue, Nov 8, 2016 at 4:50 AM, Sergi Vladykin wrote: > All the SQL statements currently run out of transactions. It is a big > feature for 2.0 > > Sergi > > 2016

Re: TX savepoints

Denis, As far as I know, there is no support for savepoints in ODBC API. ODBC drivers which implement it just detect "SAVEPOINT" keyword in query to implement this kind of functionality. Best Regards, Igor On Tue, Nov 8, 2016 at 3:50 PM, Sergi Vladykin wrote: > All the SQL statements currently

Re: TX savepoints

All the SQL statements currently run out of transactions. It is a big feature for 2.0 Sergi 2016-11-08 15:09 GMT+03:00 Igor Sapego : > Hi, > > Currently, we do not support transaction in ODBC at all. I'm not quite sure > about JDBC, but I believe we do not support them there either. As far as >

Re: TX savepoints

Hi, Currently, we do not support transaction in ODBC at all. I'm not quite sure about JDBC, but I believe we do not support them there either. As far as I know this is because we do not support transactions on the SQL level currently. Serge, can you confirm? Best Regards, Igor On Tue, Nov 8, 20

Re: TX savepoints

Couldn't agree more about ODBC and JDBC. We must support savepoints from SLQ, given the DML functionality being planned for 1.8 release. On Mon, Nov 7, 2016 at 11:23 AM, Denis Magda wrote: > This is how how the savepoints are supported by PostgreSQL [1], Oracle [2] > and MySQL [3]. The implement

Re: TX savepoints

This is how how the savepoints are supported by PostgreSQL [1], Oracle [2] and MySQL [3]. The implementation details and behavior are pretty the same and similar to the Yakov’s proposal. It worth to note that all the engines support multiple savepoints per transaction named uniquely and the REL

Re: TX savepoints

Does anyone know how MySQL or PostgreSQL work with checkpoints? Do they support it in a similar way? On Mon, Nov 7, 2016 at 5:58 AM, Yakov Zhdanov wrote: > Alex, I think we should put consecutive checkpoints to stack thus your > example should be illegal and should result to exception. And we wi

Re: TX savepoints

Alex, I think we should put consecutive checkpoints to stack thus your example should be illegal and should result to exception. And we will throw exception on rollback to CP if CP is not defined. --Yakov 2016-11-07 14:23 GMT+03:00 Alexey Goncharuk : > We also should define savepoint behavior an

Re: TX savepoints

We also should define savepoint behavior and API rules for each of the transaction concurrency and isolation types. * Should rollbackToSavepoint() always release locks or clear saved optimistic versions? * Are forward-rollbacks allowed, e.g. try (Transaction tx = ignite.transactions().txStart()

Re: TX savepoints

Hi, Yakov I suppose it's very very handy feature. My two cents are following: - number of savepoints may be more than one per transaction - what's about RELEASE SAVEPOINT statement? On Mon, Nov 7, 2016 at 11:24 AM, Yakov Zhdanov wrote: > Guys, > > Let's think of implementing savepoints for I

TX savepoints

Guys, Let's think of implementing savepoints for Ignite transactions. For me, this is not too hard to do. Having "savepoints" seems to be pretty handy. Please consider the following snippet. ignite.transactions.; INSERT INTO table1 VALUES (1); SAVEPOINT my_savepoint; INSERT INTO table1 VALUES (2