ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Игорь Г <fre...@gmail.com>
Subject Re: affinityCall in one distributed transaction
Date Tue, 13 Dec 2016 19:22:25 GMT
Dmitriy, for p.1 we can enroll it in one JTA transaction, yes.
But is there a cheaper way to do it? I think in p.2 Anton means that if we
can start ignite transaction on one client node and "join" it on other
client node (by some id) so that all changes made on 2nd client were inside
this transaction it will work much faster.




2016-12-13 12:31 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:

> On Tue, Dec 13, 2016 at 1:29 AM, Антон Чураев <churaev.an@gmail.com>
> wrote:
>
> > Using JTA in current implementation Ignite is possible. But it is
> > expensive, because currently Ignite does not support distributed
> > transaction context within all grid.
> >
> > I think it would be right to devide task into two:
> > 1) Add support of switching transactional context between multiple thread
> > within single instance jvm;
> >
>
> Can you please suggest an API for it?
>
>
> > 2) Using distributed memory for keeping transaction context;
> >
>
> What do you mean by distributed memory here?
>
>
> >
> > In my opinion, the first one is not so difficult to implement.
> >
> > 2016-12-13 1:29 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:
> >
> > > Anton,
> > >
> > > Looking at this sequence, I don't see any way of achieving it other
> than
> > > enrolling all transactions into one JTA transaction. If you seen
> another
> > > way, can you please suggest it here?
> > >
> > > D.
> > >
> > > On Sat, Dec 10, 2016 at 2:07 PM, Антон Чураев <churaev.an@gmail.com>
> > > wrote:
> > >
> > > > Dmitriy, it's ok
> > > >
> > > > To be abstract simple business transaction for execution payment
> > > > (preparation done before)  from the card looks like:
> > > > 1) Create a payment document (cache API);
> > > > 2) Write-off funds from the payer's card;
> > > > 2.1) Change in register #1 (cache API);
> > > > 2.2) Change in register #2 (cache API);
> > > > 2.3) Change in register #... (cache API);
> > > > 2.4) Change limits of card (cache API);
> > > > 3) Payment to service provider;
> > > > 3.1) Change in the balance of business unit having the contract with
> > > payer
> > > > (cache API);
> > > > 3.2) Change in the balance of business unit having the contract with
> > > > provider (cache API);
> > > > 3.3) Change in the balance of the account (cache API);
> > > > 3.4.1) Some change in registers... (cache API);
> > > > 3.4.2) ...;
> > > > 3.3) ...
> > > > 3.4) Invoke provider's API for billing payment of payer;
> > > > 4) Formation of financial statements (it's possible to implement
> > > off-line -
> > > > in other transational)
> > > > 4.1) ...
> > > > 4.2) ...
> > > >
> > > > And all steps have been designed into separate microservices. And, of
> > > > course, it have been designed via asynchronous transport.
> > > > On the other hand it seems to be that implementation of coordination
> of
> > > > 10-20 local transactions is not a good idea
> > > >
> > > > 2016-12-10 23:30 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org
> >:
> > > >
> > > > > Anton,
> > > > >
> > > > > Thanks for the explanation. I am sorry to keep asking questions on
> > > this.
> > > > > Can you change your example to include concrete Ignite calls on
> > Compute
> > > > or
> > > > > Cache APIs (or other APIs)? I am still struggling to understand the
> > > > > boundaries between business and Ignite logic.
> > > > >
> > > > > D.
> > > > >
> > > > > On Sat, Dec 10, 2016 at 5:46 AM, Антон Чураев <
> churaev.an@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > For example:
> > > > > > 1) Front-end sends a request to perform a complex transaction.
> > > > > > 2) Some application (like a business transactional coordinator)
> > > > receives
> > > > > > message via asynchronous transport. This application implements
> > logic
> > > > of
> > > > > > calling different services sequentially or in parallel via
> > > asynchronous
> > > > > > transport.
> > > > > > 3) Each service implement some little changes in a cache.
> > > > > >
> > > > > > Or:
> > > > > > 1) Front-end sends a request to perform a complex transaction.
> > > > > > 2) This transaction is implemented in microservice architecture
> > > (large
> > > > > > number microservices + asynchronous transport).
> > > > > > 3) Each microservice implement some little changes in a cache.
> > > > > >
> > > > > > I think it is possible to implement distributed transactional
> using
> > > XA
> > > > > > coordinator outside Ignite and local transaction in each service.
> > But
> > > > its
> > > > > > cost may be unacceptable especially in the case of using a large
> > > number
> > > > > of
> > > > > > services.
> > > > > >
> > > > > > I think distributed transaction inside Ignite could be useful
> also
> > > for
> > > > > > using multiple ComputeTask in one transaction.
> > > > > >
> > > > > > 2016-12-09 21:45 GMT+03:00 Dmitriy Setrakyan <
> > dsetrakyan@apache.org
> > > >:
> > > > > >
> > > > > > > Sounds like you need a centralized JTA server for this
type of
> > > > purpose,
> > > > > > no?
> > > > > > > In that case, Ignite transactions can already merge into
> ongoing
> > > JTA
> > > > > > > transactions.
> > > > > > >
> > > > > > > I would prefer to see a distributed flow of events to fully
> > > > understand
> > > > > > the
> > > > > > > issue. For example,
> > > > > > >
> > > > > > > Client
> > > > > > >   - start transaction
> > > > > > >   - send compute
> > > > > > >
> > > > > > > Server
> > > > > > >   - receive compute
> > > > > > >   - execute ...
> > > > > > >   - execute ...
> > > > > > >
> > > > > > > etc.
> > > > > > >
> > > > > > > D.
> > > > > > >
> > > > > > > On Fri, Dec 9, 2016 at 1:26 AM, Антон Чураев
<
> > churaev.an@gmail.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > In some cases it is necessary to implement a transaction
> > > processing
> > > > > > logic
> > > > > > > > in several different application servers. In this
case,
> working
> > > > with
> > > > > > > Ignite
> > > > > > > > cache will be performed within the various applications.
But
> > all
> > > > > these
> > > > > > > > changes must be made within the same distributed transaction.
> > > > > > > >
> > > > > > > > In my opinion this will require context transfer between
the
> > > > threads
> > > > > > > within
> > > > > > > > a single node or multiple Ignite nodes.
> > > > > > > >
> > > > > > > > 2016-12-08 12:53 GMT+03:00 Alexei Scherbakov <
> > > > > > > alexey.scherbakoff@gmail.com
> > > > > > > > >:
> > > > > > > >
> > > > > > > > > Hi.
> > > > > > > > >
> > > > > > > > > It's unclear from your description what are you
trying to
> > > > achieve.
> > > > > > > > >
> > > > > > > > > AffinityCall is unicast and wil be send to single
node.
> > > > > > > > >
> > > > > > > > > To parallelise task among the cluster I would
recommend to
> > use
> > > > > > compute
> > > > > > > > task
> > > > > > > > > API [1]
> > > > > > > > >
> > > > > > > > > But the task execution is not transactional.
Nevertheless,
> > each
> > > > job
> > > > > > > > > triggered by task can use it's own local transaction.
> > > > > > > > >
> > > > > > > > > And please explain, why can't you use a generic
Ignite
> > > > transaction
> > > > > > for
> > > > > > > > you
> > > > > > > > > task?
> > > > > > > > >
> > > > > > > > > [1] https://apacheignite.readme.io/docs/compute-tasks
> > > > > > > > >
> > > > > > > > > 2016-12-08 4:09 GMT+03:00 Dmitriy Setrakyan <
> > > > dsetrakyan@apache.org
> > > > > >:
> > > > > > > > >
> > > > > > > > > > Taras, is invokeAll() transactional? The
javadoc is
> silent
> > to
> > > > > this
> > > > > > > > fact.
> > > > > > > > > If
> > > > > > > > > > it is indeed transactional, then we should
update the
> > > javadoc.
> > > > > > > > > >
> > > > > > > > > > D.
> > > > > > > > > >
> > > > > > > > > > On Wed, Dec 7, 2016 at 5:32 AM, Taras Ledkov
<
> > > > > tledkov@gridgain.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Ignite compute has no relation to the
cache's
> > transaction.
> > > > > > > > > > >
> > > > > > > > > > > I think that IgniteCache.invokeAll()
is appropriate for
> > > > > described
> > > > > > > > case.
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Dec 7, 2016 at 4:00 PM, Игорь
Г <
> > frenel@gmail.com>
> > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Hi, igniters!
> > > > > > > > > > > >
> > > > > > > > > > > > Before openning JIRA ticket, I
want to ask question
> > about
> > > > > > > > > affinityCall
> > > > > > > > > > or
> > > > > > > > > > > > affinityRun transactions.
> > > > > > > > > > > >
> > > > > > > > > > > > For example I have batch task
to modify many values
> in
> > > > > > someCache
> > > > > > > > > > > according
> > > > > > > > > > > > to someRule. I want to parallel
this task to whole
> > > cluster
> > > > > and
> > > > > > > > > minimize
> > > > > > > > > > > > network traffic.
> > > > > > > > > > > > So the resonable choice is affinityCall
feature.
> > > > > > > > > > > >
> > > > > > > > > > > > But I want all this changes to
be in one transactoin.
> > > i.e.
> > > > > with
> > > > > > > at
> > > > > > > > > > least
> > > > > > > > > > > > atomicity property (of ACID).
And if for some reason
> my
> > > > task
> > > > > > will
> > > > > > > > be
> > > > > > > > > > > > canceled or failed on one node
- it should change
> > nothing
> > > > at
> > > > > > all.
> > > > > > > > > > > >
> > > > > > > > > > > > So, can I achieve this with existing
functionality,
> or
> > > how
> > > > > can
> > > > > > I
> > > > > > > > > > approach
> > > > > > > > > > > > to this task?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > >
> > > > > > > > > Best regards,
> > > > > > > > > Alexei Scherbakov
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > С уважением,
> > > > > > > > Чураев Антон
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > С уважением,
> > > > > > Чураев Антон
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > С уважением,
> > > > Чураев Антон
> > > >
> > >
> >
> >
> >
> > --
> > С уважением,
> > Чураев Антон
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message