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 <[email protected]>:

> 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 <[email protected]>:
>
> > 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 <[email protected]>
> 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, Игорь Г <[email protected]> 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
>



-- 
С уважением,
Чураев Антон

Reply via email to