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 Tue, 13 Dec 2016 09:29:38 GMT
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;
2) Using distributed memory for keeping transaction context;

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