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 13:46:21 GMT
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