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, Антон Чураев <[email protected]> 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 <[email protected]>: > > > 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, Антон Чураев <[email protected]> > 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 < > > [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 > > > > > > > > > > > > > > > > -- > > > С уважением, > > > Чураев Антон > > > > > > > > > -- > С уважением, > Чураев Антон >
