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 <sergi.vlady...@gmail.com>: > 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 <alkuznetsov...@gmail.com>: > > > Why wrong ? You know the better solution? > > > > вт, 14 мар. 2017 г. в 15:46, Sergi Vladykin <sergi.vlady...@gmail.com>: > > > > > 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 <alkuznetsov...@gmail.com > >: > > > > > > > IgniteTransactionState implememntation contains IgniteTxEntry's which > > is > > > > supposed to be transferable > > > > > > > > пн, 13 мар. 2017 г. в 19:32, Dmitriy Setrakyan < > dsetrak...@apache.org > > >: > > > > > > > > > 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 < > > > > > alkuznetsov...@gmail.com > > > > > > 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 < > > > > alkuznetsov...@gmail.com > > > > > >: > > > > > > > > > > > > > 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 < > > > > > > alexey.goncha...@gmail.com > > > > > > > >: > > > > > > > > > > > > > > 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 Дмитрий Рябов < > somefire...@gmail.com > > >: > > > > > > > > > > > > > > > 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 < > > > > > alkuznetsov...@gmail.com > > > > > > >: > > > > > > > > > > > > > > > > > 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 < > > > > > > > > alexey.goncha...@gmail.com > > > > > > > > > >: > > > > > > > > > > > > > > > > > > > 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 < > > > > > > > alkuznetsov...@gmail.com > > > > > > > > >: > > > > > > > > > > > > > > > > > > > > > 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 < > > dma...@apache.org > > > >: > > > > > > > > > > > > > > > > > > > > > > > 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 < > > > > > > > > > > > alkuznetsov...@gmail.com> > > > > > > > > > > > > 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*