ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Антон Чураев <churaev...@gmail.com>
Subject Re: affinityCall in one distributed transaction
Date Sat, 10 Dec 2016 22:07:01 GMT
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