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