distributed transaction of non-single coordinator
Locked
123
123
 
|
Hi all! Im designing distributed transaction which can be started at one
node, and continued at other one. Has anybody thoughts on it ? -- *Best Regards,* *Kuznetsov Aleksey* |
|
|
Hi Alexey,
Please share the rational behind this and the thoughts, design ideas you have in mind. — Denis > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV <[hidden email]> wrote: > > Hi all! Im designing distributed transaction which can be started at one > node, and continued at other one. Has anybody thoughts on it ? > -- > > *Best Regards,* > > *Kuznetsov Aleksey* |
|
|
Well. Consider transaction started in one node, and continued in another
one. The following test describes my idea: Ignite ignite1 = ignite(0); IgniteTransactions transactions = ignite1.transactions(); IgniteCache<String, Integer> cache = ignite1.getOrCreateCache("testCache"); Transaction tx = transactions.txStart(concurrency, isolation); cache.put("key1", 1); cache.put("key2", 2); tx.stop(); IgniteInternalFuture<Boolean> fut = GridTestUtils.runAsync(() -> { IgniteTransactions ts = ignite(1).transactions(); Assert.assertNull(ts.tx()); Assert.assertEquals(TransactionState.STOPPED, tx.state()); ts.txStart(tx); Assert.assertEquals(TransactionState.ACTIVE, tx.state()); cache.put("key3", 3); Assert.assertTrue(cache.remove("key2")); tx.commit(); return true; }); fut.get(); Assert.assertEquals(TransactionState.COMMITTED, tx.state()); Assert.assertEquals((long)1, (long)cache.get("key1")); Assert.assertEquals((long)3, (long)cache.get("key3")); Assert.assertFalse(cache.containsKey("key2")); In method *ts.txStart(...)* we just rebind *tx* to current thread: public void txStart(Transaction tx) { TransactionProxyImpl transactionProxy = (TransactionProxyImpl)tx; cctx.tm().reopenTx(transactionProxy.tx()); transactionProxy.bindToCurrentThread(); } In method *reopenTx* we alter *threadMap* so that it binds transaction to current thread. How do u think about it ? вт, 7 мар. 2017 г. в 22:38, Denis Magda <[hidden email]>: > Hi Alexey, > > Please share the rational behind this and the thoughts, design ideas you > have in mind. > > — > Denis > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV <[hidden email]> > wrote: > > > > Hi all! Im designing distributed transaction which can be started at one > > node, and continued at other one. Has anybody thoughts on it ? > > -- > > > > *Best Regards,* > > > > *Kuznetsov Aleksey* > > -- *Best Regards,* *Kuznetsov Aleksey* |
Re: distributed transaction of non-single coordinator
|
|
Aleksey,
Do you mean that you want a concept of transferring of tx ownership from one node to another? My initial understanding was that you want to be able to update keys in a transaction from multiple threads in parallel. --AG 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > Well. Consider transaction started in one node, and continued in another > one. > The following test describes my idea: > > Ignite ignite1 = ignite(0); > > IgniteTransactions transactions = ignite1.transactions(); > > IgniteCache<String, Integer> cache = ignite1.getOrCreateCache(" > testCache"); > > Transaction tx = transactions.txStart(concurrency, isolation); > > cache.put("key1", 1); > > cache.put("key2", 2); > > tx.stop(); > > IgniteInternalFuture<Boolean> fut = GridTestUtils.runAsync(() -> { > IgniteTransactions ts = ignite(1).transactions(); > Assert.assertNull(ts.tx()); > Assert.assertEquals(TransactionState.STOPPED, tx.state()); > ts.txStart(tx); > Assert.assertEquals(TransactionState.ACTIVE, tx.state()); > cache.put("key3", 3); > Assert.assertTrue(cache.remove("key2")); > tx.commit(); > return true; > }); > > fut.get(); > > Assert.assertEquals(TransactionState.COMMITTED, tx.state()); > Assert.assertEquals((long)1, (long)cache.get("key1")); > Assert.assertEquals((long)3, (long)cache.get("key3")); > Assert.assertFalse(cache.containsKey("key2")); > > In method *ts.txStart(...)* we just rebind *tx* to current thread: > > public void txStart(Transaction tx) { > TransactionProxyImpl transactionProxy = (TransactionProxyImpl)tx; > cctx.tm().reopenTx(transactionProxy.tx()); > transactionProxy.bindToCurrentThread(); > } > > In method *reopenTx* we alter *threadMap* so that it binds transaction > to current thread. > > How do u think about it ? > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda <[hidden email]>: > > > Hi Alexey, > > > > Please share the rational behind this and the thoughts, design ideas you > > have in mind. > > > > — > > Denis > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > [hidden email]> > > wrote: > > > > > > Hi all! Im designing distributed transaction which can be started at > one > > > node, and continued at other one. Has anybody thoughts on it ? > > > -- > > > > > > *Best Regards,* > > > > > > *Kuznetsov Aleksey* > > > > -- > > *Best Regards,* > > *Kuznetsov Aleksey* > |
|
|
Im aiming to span transaction on multiple threads, nodes, jvms(soon). So
every node is able to rollback, or commit common transaction.It turned up i need to transfer tx between nodes in order to commit transaction in different node(in the same jvm). пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk <[hidden email]>: > Aleksey, > > Do you mean that you want a concept of transferring of tx ownership from > one node to another? My initial understanding was that you want to be able > to update keys in a transaction from multiple threads in parallel. > > --AG > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > > > Well. Consider transaction started in one node, and continued in another > > one. > > The following test describes my idea: > > > > Ignite ignite1 = ignite(0); > > > > IgniteTransactions transactions = ignite1.transactions(); > > > > IgniteCache<String, Integer> cache = ignite1.getOrCreateCache(" > > testCache"); > > > > Transaction tx = transactions.txStart(concurrency, isolation); > > > > cache.put("key1", 1); > > > > cache.put("key2", 2); > > > > tx.stop(); > > > > IgniteInternalFuture<Boolean> fut = GridTestUtils.runAsync(() -> { > > IgniteTransactions ts = ignite(1).transactions(); > > Assert.assertNull(ts.tx()); > > Assert.assertEquals(TransactionState.STOPPED, tx.state()); > > ts.txStart(tx); > > Assert.assertEquals(TransactionState.ACTIVE, tx.state()); > > cache.put("key3", 3); > > Assert.assertTrue(cache.remove("key2")); > > tx.commit(); > > return true; > > }); > > > > fut.get(); > > > > Assert.assertEquals(TransactionState.COMMITTED, tx.state()); > > Assert.assertEquals((long)1, (long)cache.get("key1")); > > Assert.assertEquals((long)3, (long)cache.get("key3")); > > Assert.assertFalse(cache.containsKey("key2")); > > > > In method *ts.txStart(...)* we just rebind *tx* to current thread: > > > > public void txStart(Transaction tx) { > > TransactionProxyImpl transactionProxy = (TransactionProxyImpl)tx; > > cctx.tm().reopenTx(transactionProxy.tx()); > > transactionProxy.bindToCurrentThread(); > > } > > > > In method *reopenTx* we alter *threadMap* so that it binds transaction > > to current thread. > > > > How do u think about it ? > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda <[hidden email]>: > > > > > Hi Alexey, > > > > > > Please share the rational behind this and the thoughts, design ideas > you > > > have in mind. > > > > > > — > > > Denis > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > [hidden email]> > > > wrote: > > > > > > > > Hi all! Im designing distributed transaction which can be started at > > one > > > > node, and continued at other one. Has anybody thoughts on it ? > > > > -- > > > > > > > > *Best Regards,* > > > > > > > > *Kuznetsov Aleksey* > > > > > > -- > > > > *Best Regards,* > > > > *Kuznetsov Aleksey* > > > *Best Regards,* *Kuznetsov Aleksey* |
Re: distributed transaction of non-single coordinator
|
|
Alexey Goncharuk, heh, my initial understanding was that transferring of tx
ownership from one node to another will be happened automatically when originating node is gone down. 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > Im aiming to span transaction on multiple threads, nodes, jvms(soon). So > every node is able to rollback, or commit common transaction.It turned up i > need to transfer tx between nodes in order to commit transaction in > different node(in the same jvm). > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk <[hidden email] > >: > > > Aleksey, > > > > Do you mean that you want a concept of transferring of tx ownership from > > one node to another? My initial understanding was that you want to be > able > > to update keys in a transaction from multiple threads in parallel. > > > > --AG > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > > > > > Well. Consider transaction started in one node, and continued in > another > > > one. > > > The following test describes my idea: > > > > > > Ignite ignite1 = ignite(0); > > > > > > IgniteTransactions transactions = ignite1.transactions(); > > > > > > IgniteCache<String, Integer> cache = ignite1.getOrCreateCache(" > > > testCache"); > > > > > > Transaction tx = transactions.txStart(concurrency, isolation); > > > > > > cache.put("key1", 1); > > > > > > cache.put("key2", 2); > > > > > > tx.stop(); > > > > > > IgniteInternalFuture<Boolean> fut = GridTestUtils.runAsync(() -> { > > > IgniteTransactions ts = ignite(1).transactions(); > > > Assert.assertNull(ts.tx()); > > > Assert.assertEquals(TransactionState.STOPPED, tx.state()); > > > ts.txStart(tx); > > > Assert.assertEquals(TransactionState.ACTIVE, tx.state()); > > > cache.put("key3", 3); > > > Assert.assertTrue(cache.remove("key2")); > > > tx.commit(); > > > return true; > > > }); > > > > > > fut.get(); > > > > > > Assert.assertEquals(TransactionState.COMMITTED, tx.state()); > > > Assert.assertEquals((long)1, (long)cache.get("key1")); > > > Assert.assertEquals((long)3, (long)cache.get("key3")); > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > In method *ts.txStart(...)* we just rebind *tx* to current thread: > > > > > > public void txStart(Transaction tx) { > > > TransactionProxyImpl transactionProxy = (TransactionProxyImpl)tx; > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > transactionProxy.bindToCurrentThread(); > > > } > > > > > > In method *reopenTx* we alter *threadMap* so that it binds transaction > > > to current thread. > > > > > > How do u think about it ? > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda <[hidden email]>: > > > > > > > Hi Alexey, > > > > > > > > Please share the rational behind this and the thoughts, design ideas > > you > > > > have in mind. > > > > > > > > — > > > > Denis > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > [hidden email]> > > > > wrote: > > > > > > > > > > Hi all! Im designing distributed transaction which can be started > at > > > one > > > > > node, and continued at other one. Has anybody thoughts on it ? > > > > > -- > > > > > > > > > > *Best Regards,* > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > -- > > > > > > *Best Regards,* > > > > > > *Kuznetsov Aleksey* > > > > > > -- > > *Best Regards,* > > *Kuznetsov Aleksey* > |
Re: distributed transaction of non-single coordinator
|
|
Aleksey,
I think I am starting to get what you want, but I have a few concerns: - What is the API for the proposed change? In your test, you pass an instance of transaction created on ignite(0) to the ignite instance ignite(1). This is obviously not possible in a truly distributed (multi-jvm) environment. - How will you synchronize cache update actions and transaction commit? Say, you have one node that decided to commit, but another node is still writing within this transaction. How do you make sure that two nodes will not call commit() and rollback() simultaneously? - How do you make sure that either commit() or rollback() is called if an originator failed? 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов <[hidden email]>: > Alexey Goncharuk, heh, my initial understanding was that transferring of tx > ownership from one node to another will be happened automatically when > originating node is gone down. > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > > > Im aiming to span transaction on multiple threads, nodes, jvms(soon). So > > every node is able to rollback, or commit common transaction.It turned > up i > > need to transfer tx between nodes in order to commit transaction in > > different node(in the same jvm). > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > [hidden email] > > >: > > > > > Aleksey, > > > > > > Do you mean that you want a concept of transferring of tx ownership > from > > > one node to another? My initial understanding was that you want to be > > able > > > to update keys in a transaction from multiple threads in parallel. > > > > > > --AG > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email] > >: > > > > > > > Well. Consider transaction started in one node, and continued in > > another > > > > one. > > > > The following test describes my idea: > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > IgniteTransactions transactions = ignite1.transactions(); > > > > > > > > IgniteCache<String, Integer> cache = ignite1.getOrCreateCache(" > > > > testCache"); > > > > > > > > Transaction tx = transactions.txStart(concurrency, isolation); > > > > > > > > cache.put("key1", 1); > > > > > > > > cache.put("key2", 2); > > > > > > > > tx.stop(); > > > > > > > > IgniteInternalFuture<Boolean> fut = GridTestUtils.runAsync(() -> { > > > > IgniteTransactions ts = ignite(1).transactions(); > > > > Assert.assertNull(ts.tx()); > > > > Assert.assertEquals(TransactionState.STOPPED, tx.state()); > > > > ts.txStart(tx); > > > > Assert.assertEquals(TransactionState.ACTIVE, tx.state()); > > > > cache.put("key3", 3); > > > > Assert.assertTrue(cache.remove("key2")); > > > > tx.commit(); > > > > return true; > > > > }); > > > > > > > > fut.get(); > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, tx.state()); > > > > Assert.assertEquals((long)1, (long)cache.get("key1")); > > > > Assert.assertEquals((long)3, (long)cache.get("key3")); > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* to current thread: > > > > > > > > public void txStart(Transaction tx) { > > > > TransactionProxyImpl transactionProxy = (TransactionProxyImpl)tx; > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > transactionProxy.bindToCurrentThread(); > > > > } > > > > > > > > In method *reopenTx* we alter *threadMap* so that it binds > transaction > > > > to current thread. > > > > > > > > How do u think about it ? > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda <[hidden email]>: > > > > > > > > > Hi Alexey, > > > > > > > > > > Please share the rational behind this and the thoughts, design > ideas > > > you > > > > > have in mind. > > > > > > > > > > — > > > > > Denis > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > > [hidden email]> > > > > > wrote: > > > > > > > > > > > > Hi all! Im designing distributed transaction which can be started > > at > > > > one > > > > > > node, and continued at other one. Has anybody thoughts on it ? > > > > > > -- > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > -- > > > > > > > > *Best Regards,* > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > -- > > > > *Best Regards,* > > > > *Kuznetsov Aleksey* > > > |
Re: distributed transaction of non-single coordinator
|
|
What about to send special message to random/choosen node when we start
transaction? And when rollback procedure begins - this second node will check state of originating node and if it is down then second node became originating? 2017-03-10 17:25 GMT+03:00 Alexey Goncharuk <[hidden email]>: > Aleksey, > > I think I am starting to get what you want, but I have a few concerns: > - What is the API for the proposed change? In your test, you pass an > instance of transaction created on ignite(0) to the ignite instance > ignite(1). This is obviously not possible in a truly distributed > (multi-jvm) environment. > - How will you synchronize cache update actions and transaction commit? > Say, you have one node that decided to commit, but another node is still > writing within this transaction. How do you make sure that two nodes will > not call commit() and rollback() simultaneously? > - How do you make sure that either commit() or rollback() is called if an > originator failed? > > 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов <[hidden email]>: > > > Alexey Goncharuk, heh, my initial understanding was that transferring of > tx > > ownership from one node to another will be happened automatically when > > originating node is gone down. > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > > > > > Im aiming to span transaction on multiple threads, nodes, jvms(soon). > So > > > every node is able to rollback, or commit common transaction.It turned > > up i > > > need to transfer tx between nodes in order to commit transaction in > > > different node(in the same jvm). > > > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > > [hidden email] > > > >: > > > > > > > Aleksey, > > > > > > > > Do you mean that you want a concept of transferring of tx ownership > > from > > > > one node to another? My initial understanding was that you want to be > > > able > > > > to update keys in a transaction from multiple threads in parallel. > > > > > > > > --AG > > > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV < > [hidden email] > > >: > > > > > > > > > Well. Consider transaction started in one node, and continued in > > > another > > > > > one. > > > > > The following test describes my idea: > > > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > > > IgniteTransactions transactions = ignite1.transactions(); > > > > > > > > > > IgniteCache<String, Integer> cache = ignite1.getOrCreateCache(" > > > > > testCache"); > > > > > > > > > > Transaction tx = transactions.txStart(concurrency, isolation); > > > > > > > > > > cache.put("key1", 1); > > > > > > > > > > cache.put("key2", 2); > > > > > > > > > > tx.stop(); > > > > > > > > > > IgniteInternalFuture<Boolean> fut = GridTestUtils.runAsync(() -> { > > > > > IgniteTransactions ts = ignite(1).transactions(); > > > > > Assert.assertNull(ts.tx()); > > > > > Assert.assertEquals(TransactionState.STOPPED, tx.state()); > > > > > ts.txStart(tx); > > > > > Assert.assertEquals(TransactionState.ACTIVE, tx.state()); > > > > > cache.put("key3", 3); > > > > > Assert.assertTrue(cache.remove("key2")); > > > > > tx.commit(); > > > > > return true; > > > > > }); > > > > > > > > > > fut.get(); > > > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, tx.state()); > > > > > Assert.assertEquals((long)1, (long)cache.get("key1")); > > > > > Assert.assertEquals((long)3, (long)cache.get("key3")); > > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* to current thread: > > > > > > > > > > public void txStart(Transaction tx) { > > > > > TransactionProxyImpl transactionProxy = > (TransactionProxyImpl)tx; > > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > > transactionProxy.bindToCurrentThread(); > > > > > } > > > > > > > > > > In method *reopenTx* we alter *threadMap* so that it binds > > transaction > > > > > to current thread. > > > > > > > > > > How do u think about it ? > > > > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda <[hidden email]>: > > > > > > > > > > > Hi Alexey, > > > > > > > > > > > > Please share the rational behind this and the thoughts, design > > ideas > > > > you > > > > > > have in mind. > > > > > > > > > > > > — > > > > > > Denis > > > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > > > [hidden email]> > > > > > > wrote: > > > > > > > > > > > > > > Hi all! Im designing distributed transaction which can be > started > > > at > > > > > one > > > > > > > node, and continued at other one. Has anybody thoughts on it ? > > > > > > > -- > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > -- > > > > > > > > > > *Best Regards,* > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > -- > > > > > > *Best Regards,* > > > > > > *Kuznetsov Aleksey* > > > > > > |
|
|
In reply to this post by Alexey Goncharuk
- Its a draft test, in my next one i will try to serialize transaction
and send it across nodes - thats where STOPPED status comes in handy.You cannot restart transaction in another node unless it was stopped. And you cannot commit if transaction status is STOPPED. Further tests should be written to assure it works. - could you provide a simple scenario ? пт, 10 мар. 2017 г. в 17:25, Alexey Goncharuk <[hidden email]>: > Aleksey, > > I think I am starting to get what you want, but I have a few concerns: > - What is the API for the proposed change? In your test, you pass an > instance of transaction created on ignite(0) to the ignite instance > ignite(1). This is obviously not possible in a truly distributed > (multi-jvm) environment. > - How will you synchronize cache update actions and transaction commit? > Say, you have one node that decided to commit, but another node is still > writing within this transaction. How do you make sure that two nodes will > not call commit() and rollback() simultaneously? > - How do you make sure that either commit() or rollback() is called if an > originator failed? > > 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов <[hidden email]>: > > > Alexey Goncharuk, heh, my initial understanding was that transferring of > tx > > ownership from one node to another will be happened automatically when > > originating node is gone down. > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > > > > > Im aiming to span transaction on multiple threads, nodes, jvms(soon). > So > > > every node is able to rollback, or commit common transaction.It turned > > up i > > > need to transfer tx between nodes in order to commit transaction in > > > different node(in the same jvm). > > > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > > [hidden email] > > > >: > > - > > > > > > > Aleksey, > > > > > > > > Do you mean that you want a concept of transferring of tx ownership > > from > > > > one node to another? My initial understanding was that you want to be > > > able > > > > to update keys in a transaction from multiple threads in parallel. > > > > > > > > --AG > > > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV < > [hidden email] > > >: > > > > > > > > > Well. Consider transaction started in one node, and continued in > > > another > > > > > one. > > > > > The following test describes my idea: > > > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > > > IgniteTransactions transactions = ignite1.transactions(); > > > > > > > > > > IgniteCache<String, Integer> cache = ignite1.getOrCreateCache(" > > > > > testCache"); > > > > > > > > > > Transaction tx = transactions.txStart(concurrency, isolation); > > > > > > > > > > cache.put("key1", 1); > > > > > > > > > > cache.put("key2", 2); > > > > > > > > > > tx.stop(); > > > > > > > > > > IgniteInternalFuture<Boolean> fut = GridTestUtils.runAsync(() -> { > > > > > IgniteTransactions ts = ignite(1).transactions(); > > > > > Assert.assertNull(ts.tx()); > > > > > Assert.assertEquals(TransactionState.STOPPED, tx.state()); > > > > > ts.txStart(tx); > > > > > Assert.assertEquals(TransactionState.ACTIVE, tx.state()); > > > > > cache.put("key3", 3); > > > > > Assert.assertTrue(cache.remove("key2")); > > > > > tx.commit(); > > > > > return true; > > > > > }); > > > > > > > > > > fut.get(); > > > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, tx.state()); > > > > > Assert.assertEquals((long)1, (long)cache.get("key1")); > > > > > Assert.assertEquals((long)3, (long)cache.get("key3")); > > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* to current thread: > > > > > > > > > > public void txStart(Transaction tx) { > > > > > TransactionProxyImpl transactionProxy = > (TransactionProxyImpl)tx; > > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > > transactionProxy.bindToCurrentThread(); > > > > > } > > > > > > > > > > In method *reopenTx* we alter *threadMap* so that it binds > > transaction > > > > > to current thread. > > > > > > > > > > How do u think about it ? > > > > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda <[hidden email]>: > > > > > > > > > > > Hi Alexey, > > > > > > > > > > > > Please share the rational behind this and the thoughts, design > > ideas > > > > you > > > > > > have in mind. > > > > > > > > > > > > — > > > > > > Denis > > > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > > > [hidden email]> > > > > > > wrote: > > > > > > > > > > > > > > Hi all! Im designing distributed transaction which can be > started > > > at > > > > > one > > > > > > > node, and continued at other one. Has anybody thoughts on it ? > > > > > > > -- > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > -- > > > > > > > > > > *Best Regards,* > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > -- > > > > > > *Best Regards,* > > > > > > *Kuznetsov Aleksey* > > > > > > *Best Regards,* *Kuznetsov Aleksey* |
|
|
In reply to this post by Alexey Goncharuk
while starting and continuing transaction in different jvms in run into
serialization exception in writeExternalMeta : @Override public void writeExternal(ObjectOutput out) throws IOException { writeExternalMeta(out); some meta is cannot be serialized. пт, 10 мар. 2017 г. в 17:25, Alexey Goncharuk <[hidden email]>: > Aleksey, > > I think I am starting to get what you want, but I have a few concerns: > - What is the API for the proposed change? In your test, you pass an > instance of transaction created on ignite(0) to the ignite instance > ignite(1). This is obviously not possible in a truly distributed > (multi-jvm) environment. > - How will you synchronize cache update actions and transaction commit? > Say, you have one node that decided to commit, but another node is still > writing within this transaction. How do you make sure that two nodes will > not call commit() and rollback() simultaneously? > - How do you make sure that either commit() or rollback() is called if an > originator failed? > > 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов <[hidden email]>: > > > Alexey Goncharuk, heh, my initial understanding was that transferring of > tx > > ownership from one node to another will be happened automatically when > > originating node is gone down. > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > > > > > Im aiming to span transaction on multiple threads, nodes, jvms(soon). > So > > > every node is able to rollback, or commit common transaction.It turned > > up i > > > need to transfer tx between nodes in order to commit transaction in > > > different node(in the same jvm). > > > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > > [hidden email] > > > >: > > > > > > > Aleksey, > > > > > > > > Do you mean that you want a concept of transferring of tx ownership > > from > > > > one node to another? My initial understanding was that you want to be > > > able > > > > to update keys in a transaction from multiple threads in parallel. > > > > > > > > --AG > > > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV < > [hidden email] > > >: > > > > > > > > > Well. Consider transaction started in one node, and continued in > > > another > > > > > one. > > > > > The following test describes my idea: > > > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > > > IgniteTransactions transactions = ignite1.transactions(); > > > > > > > > > > IgniteCache<String, Integer> cache = ignite1.getOrCreateCache(" > > > > > testCache"); > > > > > > > > > > Transaction tx = transactions.txStart(concurrency, isolation); > > > > > > > > > > cache.put("key1", 1); > > > > > > > > > > cache.put("key2", 2); > > > > > > > > > > tx.stop(); > > > > > > > > > > IgniteInternalFuture<Boolean> fut = GridTestUtils.runAsync(() -> { > > > > > IgniteTransactions ts = ignite(1).transactions(); > > > > > Assert.assertNull(ts.tx()); > > > > > Assert.assertEquals(TransactionState.STOPPED, tx.state()); > > > > > ts.txStart(tx); > > > > > Assert.assertEquals(TransactionState.ACTIVE, tx.state()); > > > > > cache.put("key3", 3); > > > > > Assert.assertTrue(cache.remove("key2")); > > > > > tx.commit(); > > > > > return true; > > > > > }); > > > > > > > > > > fut.get(); > > > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, tx.state()); > > > > > Assert.assertEquals((long)1, (long)cache.get("key1")); > > > > > Assert.assertEquals((long)3, (long)cache.get("key3")); > > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* to current thread: > > > > > > > > > > public void txStart(Transaction tx) { > > > > > TransactionProxyImpl transactionProxy = > (TransactionProxyImpl)tx; > > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > > transactionProxy.bindToCurrentThread(); > > > > > } > > > > > > > > > > In method *reopenTx* we alter *threadMap* so that it binds > > transaction > > > > > to current thread. > > > > > > > > > > How do u think about it ? > > > > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda <[hidden email]>: > > > > > > > > > > > Hi Alexey, > > > > > > > > > > > > Please share the rational behind this and the thoughts, design > > ideas > > > > you > > > > > > have in mind. > > > > > > > > > > > > — > > > > > > Denis > > > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > > > [hidden email]> > > > > > > wrote: > > > > > > > > > > > > > > Hi all! Im designing distributed transaction which can be > started > > > at > > > > > one > > > > > > > node, and continued at other one. Has anybody thoughts on it ? > > > > > > > -- > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > -- > > > > > > > > > > *Best Regards,* > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > -- > > > > > > *Best Regards,* > > > > > > *Kuznetsov Aleksey* > > > > > > *Best Regards,* *Kuznetsov Aleksey* |
|
|
well, there a couple of issues preventing transaction proceeding.
At first, After transaction serialization and deserialization on the remote server, there is no txState. So im going to put it in writeExternal()\readExternal() The last one is Deserialized transaction lacks of shared cache context field at TransactionProxyImpl. Perhaps, it must be injected by GridResourceProcessor ? пн, 13 мар. 2017 г. в 17:27, ALEKSEY KUZNETSOV <[hidden email]>: > while starting and continuing transaction in different jvms in run into > serialization exception in writeExternalMeta : > > @Override public void writeExternal(ObjectOutput out) throws IOException { > writeExternalMeta(out); > > some meta is cannot be serialized. > пт, 10 мар. 2017 г. в 17:25, Alexey Goncharuk <[hidden email] > >: > > Aleksey, > > > > I think I am starting to get what you want, but I have a few concerns: > - What is the API for the proposed change? In your test, you pass an > instance of transaction created on ignite(0) to the ignite instance > ignite(1). This is obviously not possible in a truly distributed > (multi-jvm) environment. > - How will you synchronize cache update actions and transaction commit? > Say, you have one node that decided to commit, but another node is still > writing within this transaction. How do you make sure that two nodes will > not call commit() and rollback() simultaneously? > - How do you make sure that either commit() or rollback() is called if an > originator failed? > > 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов <[hidden email]>: > > > Alexey Goncharuk, heh, my initial understanding was that transferring of > tx > > ownership from one node to another will be happened automatically when > > originating node is gone down. > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > > > > > Im aiming to span transaction on multiple threads, nodes, jvms(soon). > So > > > every node is able to rollback, or commit common transaction.It turned > > up i > > > need to transfer tx between nodes in order to commit transaction in > > > different node(in the same jvm). > > > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > > [hidden email] > > > >: > > > > > > > Aleksey, > > > > > > > > Do you mean that you want a concept of transferring of tx ownership > > from > > > > one node to another? My initial understanding was that you want to be > > > able > > > > to update keys in a transaction from multiple threads in parallel. > > > > > > > > --AG > > > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV < > [hidden email] > > >: > > > > > > > > > Well. Consider transaction started in one node, and continued in > > > another > > > > > one. > > > > > The following test describes my idea: > > > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > > > IgniteTransactions transactions = ignite1.transactions(); > > > > > > > > > > IgniteCache<String, Integer> cache = ignite1.getOrCreateCache(" > > > > > testCache"); > > > > > > > > > > Transaction tx = transactions.txStart(concurrency, isolation); > > > > > > > > > > cache.put("key1", 1); > > > > > > > > > > cache.put("key2", 2); > > > > > > > > > > tx.stop(); > > > > > > > > > > IgniteInternalFuture<Boolean> fut = GridTestUtils.runAsync(() -> { > > > > > IgniteTransactions ts = ignite(1).transactions(); > > > > > Assert.assertNull(ts.tx()); > > > > > Assert.assertEquals(TransactionState.STOPPED, tx.state()); > > > > > ts.txStart(tx); > > > > > Assert.assertEquals(TransactionState.ACTIVE, tx.state()); > > > > > cache.put("key3", 3); > > > > > Assert.assertTrue(cache.remove("key2")); > > > > > tx.commit(); > > > > > return true; > > > > > }); > > > > > > > > > > fut.get(); > > > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, tx.state()); > > > > > Assert.assertEquals((long)1, (long)cache.get("key1")); > > > > > Assert.assertEquals((long)3, (long)cache.get("key3")); > > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* to current thread: > > > > > > > > > > public void txStart(Transaction tx) { > > > > > TransactionProxyImpl transactionProxy = > (TransactionProxyImpl)tx; > > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > > transactionProxy.bindToCurrentThread(); > > > > > } > > > > > > > > > > In method *reopenTx* we alter *threadMap* so that it binds > > transaction > > > > > to current thread. > > > > > > > > > > How do u think about it ? > > > > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda <[hidden email]>: > > > > > > > > > > > Hi Alexey, > > > > > > > > > > > > Please share the rational behind this and the thoughts, design > > ideas > > > > you > > > > > > have in mind. > > > > > > > > > > > > — > > > > > > Denis > > > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > > > [hidden email]> > > > > > > wrote: > > > > > > > > > > > > > > Hi all! Im designing distributed transaction which can be > started > > > at > > > > > one > > > > > > > node, and continued at other one. Has anybody thoughts on it ? > > > > > > > -- > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > -- > > > > > > > > > > *Best Regards,* > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > -- > > > > > > *Best Regards,* > > > > > > *Kuznetsov Aleksey* > > > > > > > -- > > *Best Regards,* > > *Kuznetsov Aleksey* > *Best Regards,* *Kuznetsov Aleksey* |
Re: distributed transaction of non-single coordinator
|
It sounds a little scary to me that we are passing transaction objects
around. Such object may contain all sorts of Ignite context. If some data needs to be passed across, we should create a special transfer object in this case. D. On Mon, Mar 13, 2017 at 9:10 AM, ALEKSEY KUZNETSOV <[hidden email] > wrote: > well, there a couple of issues preventing transaction proceeding. > At first, After transaction serialization and deserialization on the remote > server, there is no txState. So im going to put it in > writeExternal()\readExternal() > > The last one is Deserialized transaction lacks of shared cache context > field at TransactionProxyImpl. Perhaps, it must be injected by > GridResourceProcessor ? > > пн, 13 мар. 2017 г. в 17:27, ALEKSEY KUZNETSOV <[hidden email]>: > > > while starting and continuing transaction in different jvms in run into > > serialization exception in writeExternalMeta : > > > > @Override public void writeExternal(ObjectOutput out) throws IOException > { > > writeExternalMeta(out); > > > > some meta is cannot be serialized. > > пт, 10 мар. 2017 г. в 17:25, Alexey Goncharuk < > [hidden email] > > >: > > > > Aleksey, > > > > > > > > I think I am starting to get what you want, but I have a few concerns: > > - What is the API for the proposed change? In your test, you pass an > > instance of transaction created on ignite(0) to the ignite instance > > ignite(1). This is obviously not possible in a truly distributed > > (multi-jvm) environment. > > - How will you synchronize cache update actions and transaction commit? > > Say, you have one node that decided to commit, but another node is still > > writing within this transaction. How do you make sure that two nodes will > > not call commit() and rollback() simultaneously? > > - How do you make sure that either commit() or rollback() is called if > an > > originator failed? > > > > 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов <[hidden email]>: > > > > > Alexey Goncharuk, heh, my initial understanding was that transferring > of > > tx > > > ownership from one node to another will be happened automatically when > > > originating node is gone down. > > > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email] > >: > > > > > > > Im aiming to span transaction on multiple threads, nodes, jvms(soon). > > So > > > > every node is able to rollback, or commit common transaction.It > turned > > > up i > > > > need to transfer tx between nodes in order to commit transaction in > > > > different node(in the same jvm). > > > > > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > > > [hidden email] > > > > >: > > > > > > > > > Aleksey, > > > > > > > > > > Do you mean that you want a concept of transferring of tx ownership > > > from > > > > > one node to another? My initial understanding was that you want to > be > > > > able > > > > > to update keys in a transaction from multiple threads in parallel. > > > > > > > > > > --AG > > > > > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV < > > [hidden email] > > > >: > > > > > > > > > > > Well. Consider transaction started in one node, and continued in > > > > another > > > > > > one. > > > > > > The following test describes my idea: > > > > > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > > > > > IgniteTransactions transactions = ignite1.transactions(); > > > > > > > > > > > > IgniteCache<String, Integer> cache = ignite1.getOrCreateCache(" > > > > > > testCache"); > > > > > > > > > > > > Transaction tx = transactions.txStart(concurrency, isolation); > > > > > > > > > > > > cache.put("key1", 1); > > > > > > > > > > > > cache.put("key2", 2); > > > > > > > > > > > > tx.stop(); > > > > > > > > > > > > IgniteInternalFuture<Boolean> fut = GridTestUtils.runAsync(() -> > { > > > > > > IgniteTransactions ts = ignite(1).transactions(); > > > > > > Assert.assertNull(ts.tx()); > > > > > > Assert.assertEquals(TransactionState.STOPPED, tx.state()); > > > > > > ts.txStart(tx); > > > > > > Assert.assertEquals(TransactionState.ACTIVE, tx.state()); > > > > > > cache.put("key3", 3); > > > > > > Assert.assertTrue(cache.remove("key2")); > > > > > > tx.commit(); > > > > > > return true; > > > > > > }); > > > > > > > > > > > > fut.get(); > > > > > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, tx.state()); > > > > > > Assert.assertEquals((long)1, (long)cache.get("key1")); > > > > > > Assert.assertEquals((long)3, (long)cache.get("key3")); > > > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* to current > thread: > > > > > > > > > > > > public void txStart(Transaction tx) { > > > > > > TransactionProxyImpl transactionProxy = > > (TransactionProxyImpl)tx; > > > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > > > transactionProxy.bindToCurrentThread(); > > > > > > } > > > > > > > > > > > > In method *reopenTx* we alter *threadMap* so that it binds > > > transaction > > > > > > to current thread. > > > > > > > > > > > > How do u think about it ? > > > > > > > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda <[hidden email]>: > > > > > > > > > > > > > Hi Alexey, > > > > > > > > > > > > > > Please share the rational behind this and the thoughts, design > > > ideas > > > > > you > > > > > > > have in mind. > > > > > > > > > > > > > > — > > > > > > > Denis > > > > > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > > > > [hidden email]> > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi all! Im designing distributed transaction which can be > > started > > > > at > > > > > > one > > > > > > > > node, and continued at other one. Has anybody thoughts on it > ? > > > > > > > > -- > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > -- > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > -- > > > > > > > > *Best Regards,* > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > -- > > > > *Best Regards,* > > > > *Kuznetsov Aleksey* > > > -- > > *Best Regards,* > > *Kuznetsov Aleksey* > |
|
|
IgniteTransactionState implememntation contains IgniteTxEntry's which is
supposed to be transferable пн, 13 мар. 2017 г. в 19:32, Dmitriy Setrakyan <[hidden email]>: > It sounds a little scary to me that we are passing transaction objects > around. Such object may contain all sorts of Ignite context. If some data > needs to be passed across, we should create a special transfer object in > this case. > > D. > > > On Mon, Mar 13, 2017 at 9:10 AM, ALEKSEY KUZNETSOV < > [hidden email] > > wrote: > > > well, there a couple of issues preventing transaction proceeding. > > At first, After transaction serialization and deserialization on the > remote > > server, there is no txState. So im going to put it in > > writeExternal()\readExternal() > > > > The last one is Deserialized transaction lacks of shared cache context > > field at TransactionProxyImpl. Perhaps, it must be injected by > > GridResourceProcessor ? > > > > пн, 13 мар. 2017 г. в 17:27, ALEKSEY KUZNETSOV <[hidden email] > >: > > > > > while starting and continuing transaction in different jvms in run into > > > serialization exception in writeExternalMeta : > > > > > > @Override public void writeExternal(ObjectOutput out) throws > IOException > > { > > > writeExternalMeta(out); > > > > > > some meta is cannot be serialized. > > > пт, 10 мар. 2017 г. в 17:25, Alexey Goncharuk < > > [hidden email] > > > >: > > > > > > Aleksey, > > > > > > > > > > > > I think I am starting to get what you want, but I have a few concerns: > > > - What is the API for the proposed change? In your test, you pass an > > > instance of transaction created on ignite(0) to the ignite instance > > > ignite(1). This is obviously not possible in a truly distributed > > > (multi-jvm) environment. > > > - How will you synchronize cache update actions and transaction commit? > > > Say, you have one node that decided to commit, but another node is > still > > > writing within this transaction. How do you make sure that two nodes > will > > > not call commit() and rollback() simultaneously? > > > - How do you make sure that either commit() or rollback() is called if > > an > > > originator failed? > > > > > > 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов <[hidden email]>: > > > > > > > Alexey Goncharuk, heh, my initial understanding was that transferring > > of > > > tx > > > > ownership from one node to another will be happened automatically > when > > > > originating node is gone down. > > > > > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV < > [hidden email] > > >: > > > > > > > > > Im aiming to span transaction on multiple threads, nodes, > jvms(soon). > > > So > > > > > every node is able to rollback, or commit common transaction.It > > turned > > > > up i > > > > > need to transfer tx between nodes in order to commit transaction in > > > > > different node(in the same jvm). > > > > > > > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > > > > [hidden email] > > > > > >: > > > > > > > > > > > Aleksey, > > > > > > > > > > > > Do you mean that you want a concept of transferring of tx > ownership > > > > from > > > > > > one node to another? My initial understanding was that you want > to > > be > > > > > able > > > > > > to update keys in a transaction from multiple threads in > parallel. > > > > > > > > > > > > --AG > > > > > > > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV < > > > [hidden email] > > > > >: > > > > > > > > > > > > > Well. Consider transaction started in one node, and continued > in > > > > > another > > > > > > > one. > > > > > > > The following test describes my idea: > > > > > > > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > > > > > > > IgniteTransactions transactions = ignite1.transactions(); > > > > > > > > > > > > > > IgniteCache<String, Integer> cache = ignite1.getOrCreateCache(" > > > > > > > testCache"); > > > > > > > > > > > > > > Transaction tx = transactions.txStart(concurrency, isolation); > > > > > > > > > > > > > > cache.put("key1", 1); > > > > > > > > > > > > > > cache.put("key2", 2); > > > > > > > > > > > > > > tx.stop(); > > > > > > > > > > > > > > IgniteInternalFuture<Boolean> fut = GridTestUtils.runAsync(() > -> > > { > > > > > > > IgniteTransactions ts = ignite(1).transactions(); > > > > > > > Assert.assertNull(ts.tx()); > > > > > > > Assert.assertEquals(TransactionState.STOPPED, tx.state()); > > > > > > > ts.txStart(tx); > > > > > > > Assert.assertEquals(TransactionState.ACTIVE, tx.state()); > > > > > > > cache.put("key3", 3); > > > > > > > Assert.assertTrue(cache.remove("key2")); > > > > > > > tx.commit(); > > > > > > > return true; > > > > > > > }); > > > > > > > > > > > > > > fut.get(); > > > > > > > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, tx.state()); > > > > > > > Assert.assertEquals((long)1, (long)cache.get("key1")); > > > > > > > Assert.assertEquals((long)3, (long)cache.get("key3")); > > > > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* to current > > thread: > > > > > > > > > > > > > > public void txStart(Transaction tx) { > > > > > > > TransactionProxyImpl transactionProxy = > > > (TransactionProxyImpl)tx; > > > > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > > > > transactionProxy.bindToCurrentThread(); > > > > > > > } > > > > > > > > > > > > > > In method *reopenTx* we alter *threadMap* so that it binds > > > > transaction > > > > > > > to current thread. > > > > > > > > > > > > > > How do u think about it ? > > > > > > > > > > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda <[hidden email]>: > > > > > > > > > > > > > > > Hi Alexey, > > > > > > > > > > > > > > > > Please share the rational behind this and the thoughts, > design > > > > ideas > > > > > > you > > > > > > > > have in mind. > > > > > > > > > > > > > > > > — > > > > > > > > Denis > > > > > > > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > > > > > [hidden email]> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi all! Im designing distributed transaction which can be > > > started > > > > > at > > > > > > > one > > > > > > > > > node, and continued at other one. Has anybody thoughts on > it > > ? > > > > > > > > > -- > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > *Best Regards,* > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > -- > > > > > > *Best Regards,* > > > > > > *Kuznetsov Aleksey* > > > > > -- > > > > *Best Regards,* > > > > *Kuznetsov Aleksey* > > > *Best Regards,* *Kuznetsov Aleksey* |
|
|
Just serializing TX object and deserializing it on another node is
meaningless, because other nodes participating in the TX have to know about the new coordinator. This will require protocol changes, we definitely will have fault tolerance and performance issues. IMO the whole idea is wrong and it makes no sense to waste time on it. Sergi 2017-03-14 10:57 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > IgniteTransactionState implememntation contains IgniteTxEntry's which is > supposed to be transferable > > пн, 13 мар. 2017 г. в 19:32, Dmitriy Setrakyan <[hidden email]>: > > > It sounds a little scary to me that we are passing transaction objects > > around. Such object may contain all sorts of Ignite context. If some data > > needs to be passed across, we should create a special transfer object in > > this case. > > > > D. > > > > > > On Mon, Mar 13, 2017 at 9:10 AM, ALEKSEY KUZNETSOV < > > [hidden email] > > > wrote: > > > > > well, there a couple of issues preventing transaction proceeding. > > > At first, After transaction serialization and deserialization on the > > remote > > > server, there is no txState. So im going to put it in > > > writeExternal()\readExternal() > > > > > > The last one is Deserialized transaction lacks of shared cache context > > > field at TransactionProxyImpl. Perhaps, it must be injected by > > > GridResourceProcessor ? > > > > > > пн, 13 мар. 2017 г. в 17:27, ALEKSEY KUZNETSOV < > [hidden email] > > >: > > > > > > > while starting and continuing transaction in different jvms in run > into > > > > serialization exception in writeExternalMeta : > > > > > > > > @Override public void writeExternal(ObjectOutput out) throws > > IOException > > > { > > > > writeExternalMeta(out); > > > > > > > > some meta is cannot be serialized. > > > > пт, 10 мар. 2017 г. в 17:25, Alexey Goncharuk < > > > [hidden email] > > > > >: > > > > > > > > Aleksey, > > > > > > > > > > > > > > > > I think I am starting to get what you want, but I have a few > concerns: > > > > - What is the API for the proposed change? In your test, you pass an > > > > instance of transaction created on ignite(0) to the ignite instance > > > > ignite(1). This is obviously not possible in a truly distributed > > > > (multi-jvm) environment. > > > > - How will you synchronize cache update actions and transaction > commit? > > > > Say, you have one node that decided to commit, but another node is > > still > > > > writing within this transaction. How do you make sure that two nodes > > will > > > > not call commit() and rollback() simultaneously? > > > > - How do you make sure that either commit() or rollback() is called > if > > > an > > > > originator failed? > > > > > > > > 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов <[hidden email]>: > > > > > > > > > Alexey Goncharuk, heh, my initial understanding was that > transferring > > > of > > > > tx > > > > > ownership from one node to another will be happened automatically > > when > > > > > originating node is gone down. > > > > > > > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV < > > [hidden email] > > > >: > > > > > > > > > > > Im aiming to span transaction on multiple threads, nodes, > > jvms(soon). > > > > So > > > > > > every node is able to rollback, or commit common transaction.It > > > turned > > > > > up i > > > > > > need to transfer tx between nodes in order to commit transaction > in > > > > > > different node(in the same jvm). > > > > > > > > > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > > > > > [hidden email] > > > > > > >: > > > > > > > > > > > > > Aleksey, > > > > > > > > > > > > > > Do you mean that you want a concept of transferring of tx > > ownership > > > > > from > > > > > > > one node to another? My initial understanding was that you want > > to > > > be > > > > > > able > > > > > > > to update keys in a transaction from multiple threads in > > parallel. > > > > > > > > > > > > > > --AG > > > > > > > > > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV < > > > > [hidden email] > > > > > >: > > > > > > > > > > > > > > > Well. Consider transaction started in one node, and continued > > in > > > > > > another > > > > > > > > one. > > > > > > > > The following test describes my idea: > > > > > > > > > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > > > > > > > > > IgniteTransactions transactions = ignite1.transactions(); > > > > > > > > > > > > > > > > IgniteCache<String, Integer> cache = > ignite1.getOrCreateCache(" > > > > > > > > testCache"); > > > > > > > > > > > > > > > > Transaction tx = transactions.txStart(concurrency, > isolation); > > > > > > > > > > > > > > > > cache.put("key1", 1); > > > > > > > > > > > > > > > > cache.put("key2", 2); > > > > > > > > > > > > > > > > tx.stop(); > > > > > > > > > > > > > > > > IgniteInternalFuture<Boolean> fut = GridTestUtils.runAsync(() > > -> > > > { > > > > > > > > IgniteTransactions ts = ignite(1).transactions(); > > > > > > > > Assert.assertNull(ts.tx()); > > > > > > > > Assert.assertEquals(TransactionState.STOPPED, > tx.state()); > > > > > > > > ts.txStart(tx); > > > > > > > > Assert.assertEquals(TransactionState.ACTIVE, > tx.state()); > > > > > > > > cache.put("key3", 3); > > > > > > > > Assert.assertTrue(cache.remove("key2")); > > > > > > > > tx.commit(); > > > > > > > > return true; > > > > > > > > }); > > > > > > > > > > > > > > > > fut.get(); > > > > > > > > > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, tx.state()); > > > > > > > > Assert.assertEquals((long)1, (long)cache.get("key1")); > > > > > > > > Assert.assertEquals((long)3, (long)cache.get("key3")); > > > > > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* to current > > > thread: > > > > > > > > > > > > > > > > public void txStart(Transaction tx) { > > > > > > > > TransactionProxyImpl transactionProxy = > > > > (TransactionProxyImpl)tx; > > > > > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > > > > > transactionProxy.bindToCurrentThread(); > > > > > > > > } > > > > > > > > > > > > > > > > In method *reopenTx* we alter *threadMap* so that it binds > > > > > transaction > > > > > > > > to current thread. > > > > > > > > > > > > > > > > How do u think about it ? > > > > > > > > > > > > > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda <[hidden email]>: > > > > > > > > > > > > > > > > > Hi Alexey, > > > > > > > > > > > > > > > > > > Please share the rational behind this and the thoughts, > > design > > > > > ideas > > > > > > > you > > > > > > > > > have in mind. > > > > > > > > > > > > > > > > > > — > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > > > > > > [hidden email]> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi all! Im designing distributed transaction which can be > > > > started > > > > > > at > > > > > > > > one > > > > > > > > > > node, and continued at other one. Has anybody thoughts on > > it > > > ? > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > -- > > > > > > > > *Best Regards,* > > > > > > > > *Kuznetsov Aleksey* > > > > > > > -- > > > > > > *Best Regards,* > > > > > > *Kuznetsov Aleksey* > > > > > > -- > > *Best Regards,* > > *Kuznetsov Aleksey* > |
|
|
Why wrong ? You know the better solution?
вт, 14 мар. 2017 г. в 15:46, Sergi Vladykin <[hidden email]>: > Just serializing TX object and deserializing it on another node is > meaningless, because other nodes participating in the TX have to know about > the new coordinator. This will require protocol changes, we definitely will > have fault tolerance and performance issues. IMO the whole idea is wrong > and it makes no sense to waste time on it. > > Sergi > > 2017-03-14 10:57 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > > > IgniteTransactionState implememntation contains IgniteTxEntry's which is > > supposed to be transferable > > > > пн, 13 мар. 2017 г. в 19:32, Dmitriy Setrakyan <[hidden email]>: > > > > > It sounds a little scary to me that we are passing transaction objects > > > around. Such object may contain all sorts of Ignite context. If some > data > > > needs to be passed across, we should create a special transfer object > in > > > this case. > > > > > > D. > > > > > > > > > On Mon, Mar 13, 2017 at 9:10 AM, ALEKSEY KUZNETSOV < > > > [hidden email] > > > > wrote: > > > > > > > well, there a couple of issues preventing transaction proceeding. > > > > At first, After transaction serialization and deserialization on the > > > remote > > > > server, there is no txState. So im going to put it in > > > > writeExternal()\readExternal() > > > > > > > > The last one is Deserialized transaction lacks of shared cache > context > > > > field at TransactionProxyImpl. Perhaps, it must be injected by > > > > GridResourceProcessor ? > > > > > > > > пн, 13 мар. 2017 г. в 17:27, ALEKSEY KUZNETSOV < > > [hidden email] > > > >: > > > > > > > > > while starting and continuing transaction in different jvms in run > > into > > > > > serialization exception in writeExternalMeta : > > > > > > > > > > @Override public void writeExternal(ObjectOutput out) throws > > > IOException > > > > { > > > > > writeExternalMeta(out); > > > > > > > > > > some meta is cannot be serialized. > > > > > пт, 10 мар. 2017 г. в 17:25, Alexey Goncharuk < > > > > [hidden email] > > > > > >: > > > > > > > > > > Aleksey, > > > > > > > > > > > > > > > > > > > > I think I am starting to get what you want, but I have a few > > concerns: > > > > > - What is the API for the proposed change? In your test, you pass > an > > > > > instance of transaction created on ignite(0) to the ignite instance > > > > > ignite(1). This is obviously not possible in a truly distributed > > > > > (multi-jvm) environment. > > > > > - How will you synchronize cache update actions and transaction > > commit? > > > > > Say, you have one node that decided to commit, but another node is > > > still > > > > > writing within this transaction. How do you make sure that two > nodes > > > will > > > > > not call commit() and rollback() simultaneously? > > > > > - How do you make sure that either commit() or rollback() is > called > > if > > > > an > > > > > originator failed? > > > > > > > > > > 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов <[hidden email]>: > > > > > > > > > > > Alexey Goncharuk, heh, my initial understanding was that > > transferring > > > > of > > > > > tx > > > > > > ownership from one node to another will be happened automatically > > > when > > > > > > originating node is gone down. > > > > > > > > > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV < > > > [hidden email] > > > > >: > > > > > > > > > > > > > Im aiming to span transaction on multiple threads, nodes, > > > jvms(soon). > > > > > So > > > > > > > every node is able to rollback, or commit common transaction.It > > > > turned > > > > > > up i > > > > > > > need to transfer tx between nodes in order to commit > transaction > > in > > > > > > > different node(in the same jvm). > > > > > > > > > > > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > > > > > > [hidden email] > > > > > > > >: > > > > > > > > > > > > > > > Aleksey, > > > > > > > > > > > > > > > > Do you mean that you want a concept of transferring of tx > > > ownership > > > > > > from > > > > > > > > one node to another? My initial understanding was that you > want > > > to > > > > be > > > > > > > able > > > > > > > > to update keys in a transaction from multiple threads in > > > parallel. > > > > > > > > > > > > > > > > --AG > > > > > > > > > > > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV < > > > > > [hidden email] > > > > > > >: > > > > > > > > > > > > > > > > > Well. Consider transaction started in one node, and > continued > > > in > > > > > > > another > > > > > > > > > one. > > > > > > > > > The following test describes my idea: > > > > > > > > > > > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > > > > > > > > > > > IgniteTransactions transactions = ignite1.transactions(); > > > > > > > > > > > > > > > > > > IgniteCache<String, Integer> cache = > > ignite1.getOrCreateCache(" > > > > > > > > > testCache"); > > > > > > > > > > > > > > > > > > Transaction tx = transactions.txStart(concurrency, > > isolation); > > > > > > > > > > > > > > > > > > cache.put("key1", 1); > > > > > > > > > > > > > > > > > > cache.put("key2", 2); > > > > > > > > > > > > > > > > > > tx.stop(); > > > > > > > > > > > > > > > > > > IgniteInternalFuture<Boolean> fut = > GridTestUtils.runAsync(() > > > -> > > > > { > > > > > > > > > IgniteTransactions ts = ignite(1).transactions(); > > > > > > > > > Assert.assertNull(ts.tx()); > > > > > > > > > Assert.assertEquals(TransactionState.STOPPED, > > tx.state()); > > > > > > > > > ts.txStart(tx); > > > > > > > > > Assert.assertEquals(TransactionState.ACTIVE, > > tx.state()); > > > > > > > > > cache.put("key3", 3); > > > > > > > > > Assert.assertTrue(cache.remove("key2")); > > > > > > > > > tx.commit(); > > > > > > > > > return true; > > > > > > > > > }); > > > > > > > > > > > > > > > > > > fut.get(); > > > > > > > > > > > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, > tx.state()); > > > > > > > > > Assert.assertEquals((long)1, (long)cache.get("key1")); > > > > > > > > > Assert.assertEquals((long)3, (long)cache.get("key3")); > > > > > > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > > > > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* to current > > > > thread: > > > > > > > > > > > > > > > > > > public void txStart(Transaction tx) { > > > > > > > > > TransactionProxyImpl transactionProxy = > > > > > (TransactionProxyImpl)tx; > > > > > > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > > > > > > transactionProxy.bindToCurrentThread(); > > > > > > > > > } > > > > > > > > > > > > > > > > > > In method *reopenTx* we alter *threadMap* so that it binds > > > > > > transaction > > > > > > > > > to current thread. > > > > > > > > > > > > > > > > > > How do u think about it ? > > > > > > > > > > > > > > > > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda <[hidden email] > >: > > > > > > > > > > > > > > > > > > > Hi Alexey, > > > > > > > > > > > > > > > > > > > > Please share the rational behind this and the thoughts, > > > design > > > > > > ideas > > > > > > > > you > > > > > > > > > > have in mind. > > > > > > > > > > > > > > > > > > > > — > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > > > > > > > [hidden email]> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi all! Im designing distributed transaction which can > be > > > > > started > > > > > > > at > > > > > > > > > one > > > > > > > > > > > node, and continued at other one. Has anybody thoughts > on > > > it > > > > ? > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > *Best Regards,* > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > -- > > > > > > > > *Best Regards,* > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > -- > > > > *Best Regards,* > > > > *Kuznetsov Aleksey* > > > *Best Regards,* *Kuznetsov Aleksey* |
|
|
Because even if you make it work for some simplistic scenario, get ready to
write many fault tolerance tests and make sure that you TXs work gracefully in all modes in case of crashes. Also make sure that we do not have any performance drops after all your changes in existing benchmarks. All in all I don't believe these conditions will be met and your contribution will be accepted. Better solution to what problem? Sending TX to another node? The problem statement itself is already wrong. What business case you are trying to solve? I'm sure everything you need can be done in a much more simple and efficient way at the application level. Sergi 2017-03-14 16:03 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > Why wrong ? You know the better solution? > > вт, 14 мар. 2017 г. в 15:46, Sergi Vladykin <[hidden email]>: > > > Just serializing TX object and deserializing it on another node is > > meaningless, because other nodes participating in the TX have to know > about > > the new coordinator. This will require protocol changes, we definitely > will > > have fault tolerance and performance issues. IMO the whole idea is wrong > > and it makes no sense to waste time on it. > > > > Sergi > > > > 2017-03-14 10:57 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > > > > > IgniteTransactionState implememntation contains IgniteTxEntry's which > is > > > supposed to be transferable > > > > > > пн, 13 мар. 2017 г. в 19:32, Dmitriy Setrakyan <[hidden email] > >: > > > > > > > It sounds a little scary to me that we are passing transaction > objects > > > > around. Such object may contain all sorts of Ignite context. If some > > data > > > > needs to be passed across, we should create a special transfer object > > in > > > > this case. > > > > > > > > D. > > > > > > > > > > > > On Mon, Mar 13, 2017 at 9:10 AM, ALEKSEY KUZNETSOV < > > > > [hidden email] > > > > > wrote: > > > > > > > > > well, there a couple of issues preventing transaction proceeding. > > > > > At first, After transaction serialization and deserialization on > the > > > > remote > > > > > server, there is no txState. So im going to put it in > > > > > writeExternal()\readExternal() > > > > > > > > > > The last one is Deserialized transaction lacks of shared cache > > context > > > > > field at TransactionProxyImpl. Perhaps, it must be injected by > > > > > GridResourceProcessor ? > > > > > > > > > > пн, 13 мар. 2017 г. в 17:27, ALEKSEY KUZNETSOV < > > > [hidden email] > > > > >: > > > > > > > > > > > while starting and continuing transaction in different jvms in > run > > > into > > > > > > serialization exception in writeExternalMeta : > > > > > > > > > > > > @Override public void writeExternal(ObjectOutput out) throws > > > > IOException > > > > > { > > > > > > writeExternalMeta(out); > > > > > > > > > > > > some meta is cannot be serialized. > > > > > > пт, 10 мар. 2017 г. в 17:25, Alexey Goncharuk < > > > > > [hidden email] > > > > > > >: > > > > > > > > > > > > Aleksey, > > > > > > > > > > > > > > > > > > > > > > > > I think I am starting to get what you want, but I have a few > > > concerns: > > > > > > - What is the API for the proposed change? In your test, you > pass > > an > > > > > > instance of transaction created on ignite(0) to the ignite > instance > > > > > > ignite(1). This is obviously not possible in a truly distributed > > > > > > (multi-jvm) environment. > > > > > > - How will you synchronize cache update actions and transaction > > > commit? > > > > > > Say, you have one node that decided to commit, but another node > is > > > > still > > > > > > writing within this transaction. How do you make sure that two > > nodes > > > > will > > > > > > not call commit() and rollback() simultaneously? > > > > > > - How do you make sure that either commit() or rollback() is > > called > > > if > > > > > an > > > > > > originator failed? > > > > > > > > > > > > 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов <[hidden email] > >: > > > > > > > > > > > > > Alexey Goncharuk, heh, my initial understanding was that > > > transferring > > > > > of > > > > > > tx > > > > > > > ownership from one node to another will be happened > automatically > > > > when > > > > > > > originating node is gone down. > > > > > > > > > > > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV < > > > > [hidden email] > > > > > >: > > > > > > > > > > > > > > > Im aiming to span transaction on multiple threads, nodes, > > > > jvms(soon). > > > > > > So > > > > > > > > every node is able to rollback, or commit common > transaction.It > > > > > turned > > > > > > > up i > > > > > > > > need to transfer tx between nodes in order to commit > > transaction > > > in > > > > > > > > different node(in the same jvm). > > > > > > > > > > > > > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > > > > > > > [hidden email] > > > > > > > > >: > > > > > > > > > > > > > > > > > Aleksey, > > > > > > > > > > > > > > > > > > Do you mean that you want a concept of transferring of tx > > > > ownership > > > > > > > from > > > > > > > > > one node to another? My initial understanding was that you > > want > > > > to > > > > > be > > > > > > > > able > > > > > > > > > to update keys in a transaction from multiple threads in > > > > parallel. > > > > > > > > > > > > > > > > > > --AG > > > > > > > > > > > > > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV < > > > > > > [hidden email] > > > > > > > >: > > > > > > > > > > > > > > > > > > > Well. Consider transaction started in one node, and > > continued > > > > in > > > > > > > > another > > > > > > > > > > one. > > > > > > > > > > The following test describes my idea: > > > > > > > > > > > > > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > > > > > > > > > > > > > IgniteTransactions transactions = ignite1.transactions(); > > > > > > > > > > > > > > > > > > > > IgniteCache<String, Integer> cache = > > > ignite1.getOrCreateCache(" > > > > > > > > > > testCache"); > > > > > > > > > > > > > > > > > > > > Transaction tx = transactions.txStart(concurrency, > > > isolation); > > > > > > > > > > > > > > > > > > > > cache.put("key1", 1); > > > > > > > > > > > > > > > > > > > > cache.put("key2", 2); > > > > > > > > > > > > > > > > > > > > tx.stop(); > > > > > > > > > > > > > > > > > > > > IgniteInternalFuture<Boolean> fut = > > GridTestUtils.runAsync(() > > > > -> > > > > > { > > > > > > > > > > IgniteTransactions ts = ignite(1).transactions(); > > > > > > > > > > Assert.assertNull(ts.tx()); > > > > > > > > > > Assert.assertEquals(TransactionState.STOPPED, > > > tx.state()); > > > > > > > > > > ts.txStart(tx); > > > > > > > > > > Assert.assertEquals(TransactionState.ACTIVE, > > > tx.state()); > > > > > > > > > > cache.put("key3", 3); > > > > > > > > > > Assert.assertTrue(cache.remove("key2")); > > > > > > > > > > tx.commit(); > > > > > > > > > > return true; > > > > > > > > > > }); > > > > > > > > > > > > > > > > > > > > fut.get(); > > > > > > > > > > > > > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, > > tx.state()); > > > > > > > > > > Assert.assertEquals((long)1, (long)cache.get("key1")); > > > > > > > > > > Assert.assertEquals((long)3, (long)cache.get("key3")); > > > > > > > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > > > > > > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* to > current > > > > > thread: > > > > > > > > > > > > > > > > > > > > public void txStart(Transaction tx) { > > > > > > > > > > TransactionProxyImpl transactionProxy = > > > > > > (TransactionProxyImpl)tx; > > > > > > > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > > > > > > > transactionProxy.bindToCurrentThread(); > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > In method *reopenTx* we alter *threadMap* so that it > binds > > > > > > > transaction > > > > > > > > > > to current thread. > > > > > > > > > > > > > > > > > > > > How do u think about it ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda < > [hidden email] > > >: > > > > > > > > > > > > > > > > > > > > > Hi Alexey, > > > > > > > > > > > > > > > > > > > > > > Please share the rational behind this and the thoughts, > > > > design > > > > > > > ideas > > > > > > > > > you > > > > > > > > > > > have in mind. > > > > > > > > > > > > > > > > > > > > > > — > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > > > > > > > > [hidden email]> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi all! Im designing distributed transaction which > can > > be > > > > > > started > > > > > > > > at > > > > > > > > > > one > > > > > > > > > > > > node, and continued at other one. Has anybody > thoughts > > on > > > > it > > > > > ? > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > -- > > > > > > > > > > *Best Regards,* > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > -- > > > > > > *Best Regards,* > > > > > > *Kuznetsov Aleksey* > > > > > > -- > > *Best Regards,* > > *Kuznetsov Aleksey* > |
|
|
The case is the following, One starts transaction in one node, and commit
this transaction in another jvm node(or rollback it remotely). вт, 14 мар. 2017 г. в 16:30, Sergi Vladykin <[hidden email]>: > Because even if you make it work for some simplistic scenario, get ready to > write many fault tolerance tests and make sure that you TXs work gracefully > in all modes in case of crashes. Also make sure that we do not have any > performance drops after all your changes in existing benchmarks. All in all > I don't believe these conditions will be met and your contribution will be > accepted. > > Better solution to what problem? Sending TX to another node? The problem > statement itself is already wrong. What business case you are trying to > solve? I'm sure everything you need can be done in a much more simple and > efficient way at the application level. > > Sergi > > 2017-03-14 16:03 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > > > Why wrong ? You know the better solution? > > > > вт, 14 мар. 2017 г. в 15:46, Sergi Vladykin <[hidden email]>: > > > > > Just serializing TX object and deserializing it on another node is > > > meaningless, because other nodes participating in the TX have to know > > about > > > the new coordinator. This will require protocol changes, we definitely > > will > > > have fault tolerance and performance issues. IMO the whole idea is > wrong > > > and it makes no sense to waste time on it. > > > > > > Sergi > > > > > > 2017-03-14 10:57 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email] > >: > > > > > > > IgniteTransactionState implememntation contains IgniteTxEntry's which > > is > > > > supposed to be transferable > > > > > > > > пн, 13 мар. 2017 г. в 19:32, Dmitriy Setrakyan < > [hidden email] > > >: > > > > > > > > > It sounds a little scary to me that we are passing transaction > > objects > > > > > around. Such object may contain all sorts of Ignite context. If > some > > > data > > > > > needs to be passed across, we should create a special transfer > object > > > in > > > > > this case. > > > > > > > > > > D. > > > > > > > > > > > > > > > On Mon, Mar 13, 2017 at 9:10 AM, ALEKSEY KUZNETSOV < > > > > > [hidden email] > > > > > > wrote: > > > > > > > > > > > well, there a couple of issues preventing transaction proceeding. > > > > > > At first, After transaction serialization and deserialization on > > the > > > > > remote > > > > > > server, there is no txState. So im going to put it in > > > > > > writeExternal()\readExternal() > > > > > > > > > > > > The last one is Deserialized transaction lacks of shared cache > > > context > > > > > > field at TransactionProxyImpl. Perhaps, it must be injected by > > > > > > GridResourceProcessor ? > > > > > > > > > > > > пн, 13 мар. 2017 г. в 17:27, ALEKSEY KUZNETSOV < > > > > [hidden email] > > > > > >: > > > > > > > > > > > > > while starting and continuing transaction in different jvms in > > run > > > > into > > > > > > > serialization exception in writeExternalMeta : > > > > > > > > > > > > > > @Override public void writeExternal(ObjectOutput out) throws > > > > > IOException > > > > > > { > > > > > > > writeExternalMeta(out); > > > > > > > > > > > > > > some meta is cannot be serialized. > > > > > > > пт, 10 мар. 2017 г. в 17:25, Alexey Goncharuk < > > > > > > [hidden email] > > > > > > > >: > > > > > > > > > > > > > > Aleksey, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think I am starting to get what you want, but I have a few > > > > concerns: > > > > > > > - What is the API for the proposed change? In your test, you > > pass > > > an > > > > > > > instance of transaction created on ignite(0) to the ignite > > instance > > > > > > > ignite(1). This is obviously not possible in a truly > distributed > > > > > > > (multi-jvm) environment. > > > > > > > - How will you synchronize cache update actions and transaction > > > > commit? > > > > > > > Say, you have one node that decided to commit, but another node > > is > > > > > still > > > > > > > writing within this transaction. How do you make sure that two > > > nodes > > > > > will > > > > > > > not call commit() and rollback() simultaneously? > > > > > > > - How do you make sure that either commit() or rollback() is > > > called > > > > if > > > > > > an > > > > > > > originator failed? > > > > > > > > > > > > > > 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов < > [hidden email] > > >: > > > > > > > > > > > > > > > Alexey Goncharuk, heh, my initial understanding was that > > > > transferring > > > > > > of > > > > > > > tx > > > > > > > > ownership from one node to another will be happened > > automatically > > > > > when > > > > > > > > originating node is gone down. > > > > > > > > > > > > > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV < > > > > > [hidden email] > > > > > > >: > > > > > > > > > > > > > > > > > Im aiming to span transaction on multiple threads, nodes, > > > > > jvms(soon). > > > > > > > So > > > > > > > > > every node is able to rollback, or commit common > > transaction.It > > > > > > turned > > > > > > > > up i > > > > > > > > > need to transfer tx between nodes in order to commit > > > transaction > > > > in > > > > > > > > > different node(in the same jvm). > > > > > > > > > > > > > > > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > > > > > > > > [hidden email] > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > Aleksey, > > > > > > > > > > > > > > > > > > > > Do you mean that you want a concept of transferring of tx > > > > > ownership > > > > > > > > from > > > > > > > > > > one node to another? My initial understanding was that > you > > > want > > > > > to > > > > > > be > > > > > > > > > able > > > > > > > > > > to update keys in a transaction from multiple threads in > > > > > parallel. > > > > > > > > > > > > > > > > > > > > --AG > > > > > > > > > > > > > > > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV < > > > > > > > [hidden email] > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > Well. Consider transaction started in one node, and > > > continued > > > > > in > > > > > > > > > another > > > > > > > > > > > one. > > > > > > > > > > > The following test describes my idea: > > > > > > > > > > > > > > > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > > > > > > > > > > > > > > > IgniteTransactions transactions = > ignite1.transactions(); > > > > > > > > > > > > > > > > > > > > > > IgniteCache<String, Integer> cache = > > > > ignite1.getOrCreateCache(" > > > > > > > > > > > testCache"); > > > > > > > > > > > > > > > > > > > > > > Transaction tx = transactions.txStart(concurrency, > > > > isolation); > > > > > > > > > > > > > > > > > > > > > > cache.put("key1", 1); > > > > > > > > > > > > > > > > > > > > > > cache.put("key2", 2); > > > > > > > > > > > > > > > > > > > > > > tx.stop(); > > > > > > > > > > > > > > > > > > > > > > IgniteInternalFuture<Boolean> fut = > > > GridTestUtils.runAsync(() > > > > > -> > > > > > > { > > > > > > > > > > > IgniteTransactions ts = ignite(1).transactions(); > > > > > > > > > > > Assert.assertNull(ts.tx()); > > > > > > > > > > > Assert.assertEquals(TransactionState.STOPPED, > > > > tx.state()); > > > > > > > > > > > ts.txStart(tx); > > > > > > > > > > > Assert.assertEquals(TransactionState.ACTIVE, > > > > tx.state()); > > > > > > > > > > > cache.put("key3", 3); > > > > > > > > > > > Assert.assertTrue(cache.remove("key2")); > > > > > > > > > > > tx.commit(); > > > > > > > > > > > return true; > > > > > > > > > > > }); > > > > > > > > > > > > > > > > > > > > > > fut.get(); > > > > > > > > > > > > > > > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, > > > tx.state()); > > > > > > > > > > > Assert.assertEquals((long)1, (long)cache.get("key1")); > > > > > > > > > > > Assert.assertEquals((long)3, (long)cache.get("key3")); > > > > > > > > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > > > > > > > > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* to > > current > > > > > > thread: > > > > > > > > > > > > > > > > > > > > > > public void txStart(Transaction tx) { > > > > > > > > > > > TransactionProxyImpl transactionProxy = > > > > > > > (TransactionProxyImpl)tx; > > > > > > > > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > > > > > > > > transactionProxy.bindToCurrentThread(); > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > In method *reopenTx* we alter *threadMap* so that it > > binds > > > > > > > > transaction > > > > > > > > > > > to current thread. > > > > > > > > > > > > > > > > > > > > > > How do u think about it ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda < > > [hidden email] > > > >: > > > > > > > > > > > > > > > > > > > > > > > Hi Alexey, > > > > > > > > > > > > > > > > > > > > > > > > Please share the rational behind this and the > thoughts, > > > > > design > > > > > > > > ideas > > > > > > > > > > you > > > > > > > > > > > > have in mind. > > > > > > > > > > > > > > > > > > > > > > > > — > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > > > > > > > > > [hidden email]> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all! Im designing distributed transaction which > > can > > > be > > > > > > > started > > > > > > > > > at > > > > > > > > > > > one > > > > > > > > > > > > > node, and continued at other one. Has anybody > > thoughts > > > on > > > > > it > > > > > > ? > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > -- > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > -- > > > > > > > > *Best Regards,* > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > -- > > > > *Best Regards,* > > > > *Kuznetsov Aleksey* > > > *Best Regards,* *Kuznetsov Aleksey* |
|
|
Ok, it is not a business case, it is your wrong solution for it.
Lets try again, what is the business case? Sergi 2017-03-14 16:42 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > The case is the following, One starts transaction in one node, and commit > this transaction in another jvm node(or rollback it remotely). > > вт, 14 мар. 2017 г. в 16:30, Sergi Vladykin <[hidden email]>: > > > Because even if you make it work for some simplistic scenario, get ready > to > > write many fault tolerance tests and make sure that you TXs work > gracefully > > in all modes in case of crashes. Also make sure that we do not have any > > performance drops after all your changes in existing benchmarks. All in > all > > I don't believe these conditions will be met and your contribution will > be > > accepted. > > > > Better solution to what problem? Sending TX to another node? The problem > > statement itself is already wrong. What business case you are trying to > > solve? I'm sure everything you need can be done in a much more simple and > > efficient way at the application level. > > > > Sergi > > > > 2017-03-14 16:03 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > > > > > Why wrong ? You know the better solution? > > > > > > вт, 14 мар. 2017 г. в 15:46, Sergi Vladykin <[hidden email] > >: > > > > > > > Just serializing TX object and deserializing it on another node is > > > > meaningless, because other nodes participating in the TX have to know > > > about > > > > the new coordinator. This will require protocol changes, we > definitely > > > will > > > > have fault tolerance and performance issues. IMO the whole idea is > > wrong > > > > and it makes no sense to waste time on it. > > > > > > > > Sergi > > > > > > > > 2017-03-14 10:57 GMT+03:00 ALEKSEY KUZNETSOV < > [hidden email] > > >: > > > > > > > > > IgniteTransactionState implememntation contains IgniteTxEntry's > which > > > is > > > > > supposed to be transferable > > > > > > > > > > пн, 13 мар. 2017 г. в 19:32, Dmitriy Setrakyan < > > [hidden email] > > > >: > > > > > > > > > > > It sounds a little scary to me that we are passing transaction > > > objects > > > > > > around. Such object may contain all sorts of Ignite context. If > > some > > > > data > > > > > > needs to be passed across, we should create a special transfer > > object > > > > in > > > > > > this case. > > > > > > > > > > > > D. > > > > > > > > > > > > > > > > > > On Mon, Mar 13, 2017 at 9:10 AM, ALEKSEY KUZNETSOV < > > > > > > [hidden email] > > > > > > > wrote: > > > > > > > > > > > > > well, there a couple of issues preventing transaction > proceeding. > > > > > > > At first, After transaction serialization and deserialization > on > > > the > > > > > > remote > > > > > > > server, there is no txState. So im going to put it in > > > > > > > writeExternal()\readExternal() > > > > > > > > > > > > > > The last one is Deserialized transaction lacks of shared cache > > > > context > > > > > > > field at TransactionProxyImpl. Perhaps, it must be injected by > > > > > > > GridResourceProcessor ? > > > > > > > > > > > > > > пн, 13 мар. 2017 г. в 17:27, ALEKSEY KUZNETSOV < > > > > > [hidden email] > > > > > > >: > > > > > > > > > > > > > > > while starting and continuing transaction in different jvms > in > > > run > > > > > into > > > > > > > > serialization exception in writeExternalMeta : > > > > > > > > > > > > > > > > @Override public void writeExternal(ObjectOutput out) throws > > > > > > IOException > > > > > > > { > > > > > > > > writeExternalMeta(out); > > > > > > > > > > > > > > > > some meta is cannot be serialized. > > > > > > > > пт, 10 мар. 2017 г. в 17:25, Alexey Goncharuk < > > > > > > > [hidden email] > > > > > > > > >: > > > > > > > > > > > > > > > > Aleksey, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think I am starting to get what you want, but I have a few > > > > > concerns: > > > > > > > > - What is the API for the proposed change? In your test, you > > > pass > > > > an > > > > > > > > instance of transaction created on ignite(0) to the ignite > > > instance > > > > > > > > ignite(1). This is obviously not possible in a truly > > distributed > > > > > > > > (multi-jvm) environment. > > > > > > > > - How will you synchronize cache update actions and > transaction > > > > > commit? > > > > > > > > Say, you have one node that decided to commit, but another > node > > > is > > > > > > still > > > > > > > > writing within this transaction. How do you make sure that > two > > > > nodes > > > > > > will > > > > > > > > not call commit() and rollback() simultaneously? > > > > > > > > - How do you make sure that either commit() or rollback() is > > > > called > > > > > if > > > > > > > an > > > > > > > > originator failed? > > > > > > > > > > > > > > > > 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов < > > [hidden email] > > > >: > > > > > > > > > > > > > > > > > Alexey Goncharuk, heh, my initial understanding was that > > > > > transferring > > > > > > > of > > > > > > > > tx > > > > > > > > > ownership from one node to another will be happened > > > automatically > > > > > > when > > > > > > > > > originating node is gone down. > > > > > > > > > > > > > > > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV < > > > > > > [hidden email] > > > > > > > >: > > > > > > > > > > > > > > > > > > > Im aiming to span transaction on multiple threads, nodes, > > > > > > jvms(soon). > > > > > > > > So > > > > > > > > > > every node is able to rollback, or commit common > > > transaction.It > > > > > > > turned > > > > > > > > > up i > > > > > > > > > > need to transfer tx between nodes in order to commit > > > > transaction > > > > > in > > > > > > > > > > different node(in the same jvm). > > > > > > > > > > > > > > > > > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > > > > > > > > > [hidden email] > > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > Aleksey, > > > > > > > > > > > > > > > > > > > > > > Do you mean that you want a concept of transferring of > tx > > > > > > ownership > > > > > > > > > from > > > > > > > > > > > one node to another? My initial understanding was that > > you > > > > want > > > > > > to > > > > > > > be > > > > > > > > > > able > > > > > > > > > > > to update keys in a transaction from multiple threads > in > > > > > > parallel. > > > > > > > > > > > > > > > > > > > > > > --AG > > > > > > > > > > > > > > > > > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV < > > > > > > > > [hidden email] > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > Well. Consider transaction started in one node, and > > > > continued > > > > > > in > > > > > > > > > > another > > > > > > > > > > > > one. > > > > > > > > > > > > The following test describes my idea: > > > > > > > > > > > > > > > > > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > > > > > > > > > > > > > > > > > IgniteTransactions transactions = > > ignite1.transactions(); > > > > > > > > > > > > > > > > > > > > > > > > IgniteCache<String, Integer> cache = > > > > > ignite1.getOrCreateCache(" > > > > > > > > > > > > testCache"); > > > > > > > > > > > > > > > > > > > > > > > > Transaction tx = transactions.txStart(concurrency, > > > > > isolation); > > > > > > > > > > > > > > > > > > > > > > > > cache.put("key1", 1); > > > > > > > > > > > > > > > > > > > > > > > > cache.put("key2", 2); > > > > > > > > > > > > > > > > > > > > > > > > tx.stop(); > > > > > > > > > > > > > > > > > > > > > > > > IgniteInternalFuture<Boolean> fut = > > > > GridTestUtils.runAsync(() > > > > > > -> > > > > > > > { > > > > > > > > > > > > IgniteTransactions ts = ignite(1).transactions(); > > > > > > > > > > > > Assert.assertNull(ts.tx()); > > > > > > > > > > > > Assert.assertEquals(TransactionState.STOPPED, > > > > > tx.state()); > > > > > > > > > > > > ts.txStart(tx); > > > > > > > > > > > > Assert.assertEquals(TransactionState.ACTIVE, > > > > > tx.state()); > > > > > > > > > > > > cache.put("key3", 3); > > > > > > > > > > > > Assert.assertTrue(cache.remove("key2")); > > > > > > > > > > > > tx.commit(); > > > > > > > > > > > > return true; > > > > > > > > > > > > }); > > > > > > > > > > > > > > > > > > > > > > > > fut.get(); > > > > > > > > > > > > > > > > > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, > > > > tx.state()); > > > > > > > > > > > > Assert.assertEquals((long)1, > (long)cache.get("key1")); > > > > > > > > > > > > Assert.assertEquals((long)3, > (long)cache.get("key3")); > > > > > > > > > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > > > > > > > > > > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* to > > > current > > > > > > > thread: > > > > > > > > > > > > > > > > > > > > > > > > public void txStart(Transaction tx) { > > > > > > > > > > > > TransactionProxyImpl transactionProxy = > > > > > > > > (TransactionProxyImpl)tx; > > > > > > > > > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > > > > > > > > > transactionProxy.bindToCurrentThread(); > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > In method *reopenTx* we alter *threadMap* so that it > > > binds > > > > > > > > > transaction > > > > > > > > > > > > to current thread. > > > > > > > > > > > > > > > > > > > > > > > > How do u think about it ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda < > > > [hidden email] > > > > >: > > > > > > > > > > > > > > > > > > > > > > > > > Hi Alexey, > > > > > > > > > > > > > > > > > > > > > > > > > > Please share the rational behind this and the > > thoughts, > > > > > > design > > > > > > > > > ideas > > > > > > > > > > > you > > > > > > > > > > > > > have in mind. > > > > > > > > > > > > > > > > > > > > > > > > > > — > > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > > > > > > > > > > [hidden email]> > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all! Im designing distributed transaction > which > > > can > > > > be > > > > > > > > started > > > > > > > > > > at > > > > > > > > > > > > one > > > > > > > > > > > > > > node, and continued at other one. Has anybody > > > thoughts > > > > on > > > > > > it > > > > > > > ? > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > *Best Regards,* > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > -- > > > > > > *Best Regards,* > > > > > > *Kuznetsov Aleksey* > > > > > > -- > > *Best Regards,* > > *Kuznetsov Aleksey* > |
|
|
Fine. Let's say we've got multiple servers which fulfills custom logic.
This servers compound oriented graph (BPMN process) which controlled by Orchestrator. For instance, *server1 *creates *variable A *with value 1, persists it to IGNITE cache and creates *variable B *and sends it to* server2. *The latests receives *variable B*, do some logic with it and stores to IGNITE. All the work made by both servers must be fulfilled in *one* transaction. Because we need all information done, or nothing(rollbacked). The scenario is managed by orchestrator. вт, 14 мар. 2017 г. в 17:31, Sergi Vladykin <[hidden email]>: > Ok, it is not a business case, it is your wrong solution for it. > Lets try again, what is the business case? > > Sergi > > 2017-03-14 16:42 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > > > The case is the following, One starts transaction in one node, and commit > > this transaction in another jvm node(or rollback it remotely). > > > > вт, 14 мар. 2017 г. в 16:30, Sergi Vladykin <[hidden email]>: > > > > > Because even if you make it work for some simplistic scenario, get > ready > > to > > > write many fault tolerance tests and make sure that you TXs work > > gracefully > > > in all modes in case of crashes. Also make sure that we do not have any > > > performance drops after all your changes in existing benchmarks. All in > > all > > > I don't believe these conditions will be met and your contribution will > > be > > > accepted. > > > > > > Better solution to what problem? Sending TX to another node? The > problem > > > statement itself is already wrong. What business case you are trying to > > > solve? I'm sure everything you need can be done in a much more simple > and > > > efficient way at the application level. > > > > > > Sergi > > > > > > 2017-03-14 16:03 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email] > >: > > > > > > > Why wrong ? You know the better solution? > > > > > > > > вт, 14 мар. 2017 г. в 15:46, Sergi Vladykin < > [hidden email] > > >: > > > > > > > > > Just serializing TX object and deserializing it on another node is > > > > > meaningless, because other nodes participating in the TX have to > know > > > > about > > > > > the new coordinator. This will require protocol changes, we > > definitely > > > > will > > > > > have fault tolerance and performance issues. IMO the whole idea is > > > wrong > > > > > and it makes no sense to waste time on it. > > > > > > > > > > Sergi > > > > > > > > > > 2017-03-14 10:57 GMT+03:00 ALEKSEY KUZNETSOV < > > [hidden email] > > > >: > > > > > > > > > > > IgniteTransactionState implememntation contains IgniteTxEntry's > > which > > > > is > > > > > > supposed to be transferable > > > > > > > > > > > > пн, 13 мар. 2017 г. в 19:32, Dmitriy Setrakyan < > > > [hidden email] > > > > >: > > > > > > > > > > > > > It sounds a little scary to me that we are passing transaction > > > > objects > > > > > > > around. Such object may contain all sorts of Ignite context. If > > > some > > > > > data > > > > > > > needs to be passed across, we should create a special transfer > > > object > > > > > in > > > > > > > this case. > > > > > > > > > > > > > > D. > > > > > > > > > > > > > > > > > > > > > On Mon, Mar 13, 2017 at 9:10 AM, ALEKSEY KUZNETSOV < > > > > > > > [hidden email] > > > > > > > > wrote: > > > > > > > > > > > > > > > well, there a couple of issues preventing transaction > > proceeding. > > > > > > > > At first, After transaction serialization and deserialization > > on > > > > the > > > > > > > remote > > > > > > > > server, there is no txState. So im going to put it in > > > > > > > > writeExternal()\readExternal() > > > > > > > > > > > > > > > > The last one is Deserialized transaction lacks of shared > cache > > > > > context > > > > > > > > field at TransactionProxyImpl. Perhaps, it must be injected > by > > > > > > > > GridResourceProcessor ? > > > > > > > > > > > > > > > > пн, 13 мар. 2017 г. в 17:27, ALEKSEY KUZNETSOV < > > > > > > [hidden email] > > > > > > > >: > > > > > > > > > > > > > > > > > while starting and continuing transaction in different jvms > > in > > > > run > > > > > > into > > > > > > > > > serialization exception in writeExternalMeta : > > > > > > > > > > > > > > > > > > @Override public void writeExternal(ObjectOutput out) > throws > > > > > > > IOException > > > > > > > > { > > > > > > > > > writeExternalMeta(out); > > > > > > > > > > > > > > > > > > some meta is cannot be serialized. > > > > > > > > > пт, 10 мар. 2017 г. в 17:25, Alexey Goncharuk < > > > > > > > > [hidden email] > > > > > > > > > >: > > > > > > > > > > > > > > > > > > Aleksey, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think I am starting to get what you want, but I have a > few > > > > > > concerns: > > > > > > > > > - What is the API for the proposed change? In your test, > you > > > > pass > > > > > an > > > > > > > > > instance of transaction created on ignite(0) to the ignite > > > > instance > > > > > > > > > ignite(1). This is obviously not possible in a truly > > > distributed > > > > > > > > > (multi-jvm) environment. > > > > > > > > > - How will you synchronize cache update actions and > > transaction > > > > > > commit? > > > > > > > > > Say, you have one node that decided to commit, but another > > node > > > > is > > > > > > > still > > > > > > > > > writing within this transaction. How do you make sure that > > two > > > > > nodes > > > > > > > will > > > > > > > > > not call commit() and rollback() simultaneously? > > > > > > > > > - How do you make sure that either commit() or rollback() > is > > > > > called > > > > > > if > > > > > > > > an > > > > > > > > > originator failed? > > > > > > > > > > > > > > > > > > 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов < > > > [hidden email] > > > > >: > > > > > > > > > > > > > > > > > > > Alexey Goncharuk, heh, my initial understanding was that > > > > > > transferring > > > > > > > > of > > > > > > > > > tx > > > > > > > > > > ownership from one node to another will be happened > > > > automatically > > > > > > > when > > > > > > > > > > originating node is gone down. > > > > > > > > > > > > > > > > > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV < > > > > > > > [hidden email] > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > Im aiming to span transaction on multiple threads, > nodes, > > > > > > > jvms(soon). > > > > > > > > > So > > > > > > > > > > > every node is able to rollback, or commit common > > > > transaction.It > > > > > > > > turned > > > > > > > > > > up i > > > > > > > > > > > need to transfer tx between nodes in order to commit > > > > > transaction > > > > > > in > > > > > > > > > > > different node(in the same jvm). > > > > > > > > > > > > > > > > > > > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > > > > > > > > > > [hidden email] > > > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > Aleksey, > > > > > > > > > > > > > > > > > > > > > > > > Do you mean that you want a concept of transferring > of > > tx > > > > > > > ownership > > > > > > > > > > from > > > > > > > > > > > > one node to another? My initial understanding was > that > > > you > > > > > want > > > > > > > to > > > > > > > > be > > > > > > > > > > > able > > > > > > > > > > > > to update keys in a transaction from multiple threads > > in > > > > > > > parallel. > > > > > > > > > > > > > > > > > > > > > > > > --AG > > > > > > > > > > > > > > > > > > > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV < > > > > > > > > > [hidden email] > > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > > > Well. Consider transaction started in one node, and > > > > > continued > > > > > > > in > > > > > > > > > > > another > > > > > > > > > > > > > one. > > > > > > > > > > > > > The following test describes my idea: > > > > > > > > > > > > > > > > > > > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > > > > > > > > > > > > > > > > > > > IgniteTransactions transactions = > > > ignite1.transactions(); > > > > > > > > > > > > > > > > > > > > > > > > > > IgniteCache<String, Integer> cache = > > > > > > ignite1.getOrCreateCache(" > > > > > > > > > > > > > testCache"); > > > > > > > > > > > > > > > > > > > > > > > > > > Transaction tx = transactions.txStart(concurrency, > > > > > > isolation); > > > > > > > > > > > > > > > > > > > > > > > > > > cache.put("key1", 1); > > > > > > > > > > > > > > > > > > > > > > > > > > cache.put("key2", 2); > > > > > > > > > > > > > > > > > > > > > > > > > > tx.stop(); > > > > > > > > > > > > > > > > > > > > > > > > > > IgniteInternalFuture<Boolean> fut = > > > > > GridTestUtils.runAsync(() > > > > > > > -> > > > > > > > > { > > > > > > > > > > > > > IgniteTransactions ts = > ignite(1).transactions(); > > > > > > > > > > > > > Assert.assertNull(ts.tx()); > > > > > > > > > > > > > Assert.assertEquals(TransactionState.STOPPED, > > > > > > tx.state()); > > > > > > > > > > > > > ts.txStart(tx); > > > > > > > > > > > > > Assert.assertEquals(TransactionState.ACTIVE, > > > > > > tx.state()); > > > > > > > > > > > > > cache.put("key3", 3); > > > > > > > > > > > > > Assert.assertTrue(cache.remove("key2")); > > > > > > > > > > > > > tx.commit(); > > > > > > > > > > > > > return true; > > > > > > > > > > > > > }); > > > > > > > > > > > > > > > > > > > > > > > > > > fut.get(); > > > > > > > > > > > > > > > > > > > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, > > > > > tx.state()); > > > > > > > > > > > > > Assert.assertEquals((long)1, > > (long)cache.get("key1")); > > > > > > > > > > > > > Assert.assertEquals((long)3, > > (long)cache.get("key3")); > > > > > > > > > > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > > > > > > > > > > > > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* to > > > > current > > > > > > > > thread: > > > > > > > > > > > > > > > > > > > > > > > > > > public void txStart(Transaction tx) { > > > > > > > > > > > > > TransactionProxyImpl transactionProxy = > > > > > > > > > (TransactionProxyImpl)tx; > > > > > > > > > > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > > > > > > > > > > transactionProxy.bindToCurrentThread(); > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > In method *reopenTx* we alter *threadMap* so that > it > > > > binds > > > > > > > > > > transaction > > > > > > > > > > > > > to current thread. > > > > > > > > > > > > > > > > > > > > > > > > > > How do u think about it ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda < > > > > [hidden email] > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Alexey, > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please share the rational behind this and the > > > thoughts, > > > > > > > design > > > > > > > > > > ideas > > > > > > > > > > > > you > > > > > > > > > > > > > > have in mind. > > > > > > > > > > > > > > > > > > > > > > > > > > > > — > > > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV < > > > > > > > > > > > > > [hidden email]> > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all! Im designing distributed transaction > > which > > > > can > > > > > be > > > > > > > > > started > > > > > > > > > > > at > > > > > > > > > > > > > one > > > > > > > > > > > > > > > node, and continued at other one. Has anybody > > > > thoughts > > > > > on > > > > > > > it > > > > > > > > ? > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > -- > > > > > > > > *Best Regards,* > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > -- > > > > *Best Regards,* > > > > *Kuznetsov Aleksey* > > > *Best Regards,* *Kuznetsov Aleksey* |
|
|
What is Orchestrator for you? Is it a thing from Microsoft or your custom
in-house software? Sergi 2017-03-14 18:00 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > Fine. Let's say we've got multiple servers which fulfills custom logic. > This servers compound oriented graph (BPMN process) which controlled by > Orchestrator. > For instance, *server1 *creates *variable A *with value 1, persists it to > IGNITE cache and creates *variable B *and sends it to* server2. *The > latests receives *variable B*, do some logic with it and stores to IGNITE. > All the work made by both servers must be fulfilled in *one* transaction. > Because we need all information done, or nothing(rollbacked). The scenario > is managed by orchestrator. > > вт, 14 мар. 2017 г. в 17:31, Sergi Vladykin <[hidden email]>: > > > Ok, it is not a business case, it is your wrong solution for it. > > Lets try again, what is the business case? > > > > Sergi > > > > 2017-03-14 16:42 GMT+03:00 ALEKSEY KUZNETSOV <[hidden email]>: > > > > > The case is the following, One starts transaction in one node, and > commit > > > this transaction in another jvm node(or rollback it remotely). > > > > > > вт, 14 мар. 2017 г. в 16:30, Sergi Vladykin <[hidden email] > >: > > > > > > > Because even if you make it work for some simplistic scenario, get > > ready > > > to > > > > write many fault tolerance tests and make sure that you TXs work > > > gracefully > > > > in all modes in case of crashes. Also make sure that we do not have > any > > > > performance drops after all your changes in existing benchmarks. All > in > > > all > > > > I don't believe these conditions will be met and your contribution > will > > > be > > > > accepted. > > > > > > > > Better solution to what problem? Sending TX to another node? The > > problem > > > > statement itself is already wrong. What business case you are trying > to > > > > solve? I'm sure everything you need can be done in a much more simple > > and > > > > efficient way at the application level. > > > > > > > > Sergi > > > > > > > > 2017-03-14 16:03 GMT+03:00 ALEKSEY KUZNETSOV < > [hidden email] > > >: > > > > > > > > > Why wrong ? You know the better solution? > > > > > > > > > > вт, 14 мар. 2017 г. в 15:46, Sergi Vladykin < > > [hidden email] > > > >: > > > > > > > > > > > Just serializing TX object and deserializing it on another node > is > > > > > > meaningless, because other nodes participating in the TX have to > > know > > > > > about > > > > > > the new coordinator. This will require protocol changes, we > > > definitely > > > > > will > > > > > > have fault tolerance and performance issues. IMO the whole idea > is > > > > wrong > > > > > > and it makes no sense to waste time on it. > > > > > > > > > > > > Sergi > > > > > > > > > > > > 2017-03-14 10:57 GMT+03:00 ALEKSEY KUZNETSOV < > > > [hidden email] > > > > >: > > > > > > > > > > > > > IgniteTransactionState implememntation contains IgniteTxEntry's > > > which > > > > > is > > > > > > > supposed to be transferable > > > > > > > > > > > > > > пн, 13 мар. 2017 г. в 19:32, Dmitriy Setrakyan < > > > > [hidden email] > > > > > >: > > > > > > > > > > > > > > > It sounds a little scary to me that we are passing > transaction > > > > > objects > > > > > > > > around. Such object may contain all sorts of Ignite context. > If > > > > some > > > > > > data > > > > > > > > needs to be passed across, we should create a special > transfer > > > > object > > > > > > in > > > > > > > > this case. > > > > > > > > > > > > > > > > D. > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Mar 13, 2017 at 9:10 AM, ALEKSEY KUZNETSOV < > > > > > > > > [hidden email] > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > well, there a couple of issues preventing transaction > > > proceeding. > > > > > > > > > At first, After transaction serialization and > deserialization > > > on > > > > > the > > > > > > > > remote > > > > > > > > > server, there is no txState. So im going to put it in > > > > > > > > > writeExternal()\readExternal() > > > > > > > > > > > > > > > > > > The last one is Deserialized transaction lacks of shared > > cache > > > > > > context > > > > > > > > > field at TransactionProxyImpl. Perhaps, it must be injected > > by > > > > > > > > > GridResourceProcessor ? > > > > > > > > > > > > > > > > > > пн, 13 мар. 2017 г. в 17:27, ALEKSEY KUZNETSOV < > > > > > > > [hidden email] > > > > > > > > >: > > > > > > > > > > > > > > > > > > > while starting and continuing transaction in different > jvms > > > in > > > > > run > > > > > > > into > > > > > > > > > > serialization exception in writeExternalMeta : > > > > > > > > > > > > > > > > > > > > @Override public void writeExternal(ObjectOutput out) > > throws > > > > > > > > IOException > > > > > > > > > { > > > > > > > > > > writeExternalMeta(out); > > > > > > > > > > > > > > > > > > > > some meta is cannot be serialized. > > > > > > > > > > пт, 10 мар. 2017 г. в 17:25, Alexey Goncharuk < > > > > > > > > > [hidden email] > > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > Aleksey, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think I am starting to get what you want, but I have a > > few > > > > > > > concerns: > > > > > > > > > > - What is the API for the proposed change? In your test, > > you > > > > > pass > > > > > > an > > > > > > > > > > instance of transaction created on ignite(0) to the > ignite > > > > > instance > > > > > > > > > > ignite(1). This is obviously not possible in a truly > > > > distributed > > > > > > > > > > (multi-jvm) environment. > > > > > > > > > > - How will you synchronize cache update actions and > > > transaction > > > > > > > commit? > > > > > > > > > > Say, you have one node that decided to commit, but > another > > > node > > > > > is > > > > > > > > still > > > > > > > > > > writing within this transaction. How do you make sure > that > > > two > > > > > > nodes > > > > > > > > will > > > > > > > > > > not call commit() and rollback() simultaneously? > > > > > > > > > > - How do you make sure that either commit() or > rollback() > > is > > > > > > called > > > > > > > if > > > > > > > > > an > > > > > > > > > > originator failed? > > > > > > > > > > > > > > > > > > > > 2017-03-10 15:38 GMT+03:00 Дмитрий Рябов < > > > > [hidden email] > > > > > >: > > > > > > > > > > > > > > > > > > > > > Alexey Goncharuk, heh, my initial understanding was > that > > > > > > > transferring > > > > > > > > > of > > > > > > > > > > tx > > > > > > > > > > > ownership from one node to another will be happened > > > > > automatically > > > > > > > > when > > > > > > > > > > > originating node is gone down. > > > > > > > > > > > > > > > > > > > > > > 2017-03-10 15:36 GMT+03:00 ALEKSEY KUZNETSOV < > > > > > > > > [hidden email] > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > Im aiming to span transaction on multiple threads, > > nodes, > > > > > > > > jvms(soon). > > > > > > > > > > So > > > > > > > > > > > > every node is able to rollback, or commit common > > > > > transaction.It > > > > > > > > > turned > > > > > > > > > > > up i > > > > > > > > > > > > need to transfer tx between nodes in order to commit > > > > > > transaction > > > > > > > in > > > > > > > > > > > > different node(in the same jvm). > > > > > > > > > > > > > > > > > > > > > > > > пт, 10 мар. 2017 г. в 15:20, Alexey Goncharuk < > > > > > > > > > > > [hidden email] > > > > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > > > Aleksey, > > > > > > > > > > > > > > > > > > > > > > > > > > Do you mean that you want a concept of transferring > > of > > > tx > > > > > > > > ownership > > > > > > > > > > > from > > > > > > > > > > > > > one node to another? My initial understanding was > > that > > > > you > > > > > > want > > > > > > > > to > > > > > > > > > be > > > > > > > > > > > > able > > > > > > > > > > > > > to update keys in a transaction from multiple > threads > > > in > > > > > > > > parallel. > > > > > > > > > > > > > > > > > > > > > > > > > > --AG > > > > > > > > > > > > > > > > > > > > > > > > > > 2017-03-10 15:01 GMT+03:00 ALEKSEY KUZNETSOV < > > > > > > > > > > [hidden email] > > > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > > > > > Well. Consider transaction started in one node, > and > > > > > > continued > > > > > > > > in > > > > > > > > > > > > another > > > > > > > > > > > > > > one. > > > > > > > > > > > > > > The following test describes my idea: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Ignite ignite1 = ignite(0); > > > > > > > > > > > > > > > > > > > > > > > > > > > > IgniteTransactions transactions = > > > > ignite1.transactions(); > > > > > > > > > > > > > > > > > > > > > > > > > > > > IgniteCache<String, Integer> cache = > > > > > > > ignite1.getOrCreateCache(" > > > > > > > > > > > > > > testCache"); > > > > > > > > > > > > > > > > > > > > > > > > > > > > Transaction tx = transactions.txStart( > concurrency, > > > > > > > isolation); > > > > > > > > > > > > > > > > > > > > > > > > > > > > cache.put("key1", 1); > > > > > > > > > > > > > > > > > > > > > > > > > > > > cache.put("key2", 2); > > > > > > > > > > > > > > > > > > > > > > > > > > > > tx.stop(); > > > > > > > > > > > > > > > > > > > > > > > > > > > > IgniteInternalFuture<Boolean> fut = > > > > > > GridTestUtils.runAsync(() > > > > > > > > -> > > > > > > > > > { > > > > > > > > > > > > > > IgniteTransactions ts = > > ignite(1).transactions(); > > > > > > > > > > > > > > Assert.assertNull(ts.tx()); > > > > > > > > > > > > > > Assert.assertEquals( > TransactionState.STOPPED, > > > > > > > tx.state()); > > > > > > > > > > > > > > ts.txStart(tx); > > > > > > > > > > > > > > Assert.assertEquals(TransactionState.ACTIVE, > > > > > > > tx.state()); > > > > > > > > > > > > > > cache.put("key3", 3); > > > > > > > > > > > > > > Assert.assertTrue(cache.remove("key2")); > > > > > > > > > > > > > > tx.commit(); > > > > > > > > > > > > > > return true; > > > > > > > > > > > > > > }); > > > > > > > > > > > > > > > > > > > > > > > > > > > > fut.get(); > > > > > > > > > > > > > > > > > > > > > > > > > > > > Assert.assertEquals(TransactionState.COMMITTED, > > > > > > tx.state()); > > > > > > > > > > > > > > Assert.assertEquals((long)1, > > > (long)cache.get("key1")); > > > > > > > > > > > > > > Assert.assertEquals((long)3, > > > (long)cache.get("key3")); > > > > > > > > > > > > > > Assert.assertFalse(cache.containsKey("key2")); > > > > > > > > > > > > > > > > > > > > > > > > > > > > In method *ts.txStart(...)* we just rebind *tx* > to > > > > > current > > > > > > > > > thread: > > > > > > > > > > > > > > > > > > > > > > > > > > > > public void txStart(Transaction tx) { > > > > > > > > > > > > > > TransactionProxyImpl transactionProxy = > > > > > > > > > > (TransactionProxyImpl)tx; > > > > > > > > > > > > > > cctx.tm().reopenTx(transactionProxy.tx()); > > > > > > > > > > > > > > transactionProxy.bindToCurrentThread(); > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > > > > > > > > > > > > > In method *reopenTx* we alter *threadMap* so that > > it > > > > > binds > > > > > > > > > > > transaction > > > > > > > > > > > > > > to current thread. > > > > > > > > > > > > > > > > > > > > > > > > > > > > How do u think about it ? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > вт, 7 мар. 2017 г. в 22:38, Denis Magda < > > > > > [hidden email] > > > > > > >: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Alexey, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Please share the rational behind this and the > > > > thoughts, > > > > > > > > design > > > > > > > > > > > ideas > > > > > > > > > > > > > you > > > > > > > > > > > > > > > have in mind. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > — > > > > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mar 7, 2017, at 3:19 AM, ALEKSEY > KUZNETSOV < > > > > > > > > > > > > > > [hidden email]> > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all! Im designing distributed transaction > > > which > > > > > can > > > > > > be > > > > > > > > > > started > > > > > > > > > > > > at > > > > > > > > > > > > > > one > > > > > > > > > > > > > > > > node, and continued at other one. Has anybody > > > > > thoughts > > > > > > on > > > > > > > > it > > > > > > > > > ? > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > *Best Regards,* > > > > > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > *Best Regards,* > > > > > > > > > > *Kuznetsov Aleksey* > > > > > > > > > > > > -- > > > > > > *Best Regards,* > > > > > > *Kuznetsov Aleksey* > > > > > > -- > > *Best Regards,* > > *Kuznetsov Aleksey* > |
«
Return to Apache Ignite Developers - Legacy Mail Archive
|
1 view|%1 views
| Free forum by Nabble | Edit this page |