Nick I see no difficulty in assinging each cancellable object an IgniteUuid (which is actually java UUID and is guaranteed to be unique per node). We can have registry of running queries and just poking to what registry is enough to understand query type.
чт, 6 февр. 2020 г. в 17:17, Вячеслав Коптилин <[email protected]>: > Hello, > > It seems to me we missed API that should be introduced into control > utility. > Nikolay, could you please note this requirement on the IEP page? > > Thanks, > S. > > чт, 6 февр. 2020 г. в 15:29, Nikolay Izhikov <[email protected]>: > > > Ticket [1] created. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12632 > > > > > 5 февр. 2020 г., в 15:36, Nikolay Izhikov <[email protected]> > > написал(а): > > > > > > Alexey. > > > > > > I’m talking the following scenario: > > > > > > 1. Consider we have unified bean to kill tasks: > > > > > > CancelMXBean { > > > public void cancel(long id); > > > } > > > > > > 2. And we have the following log: > > > > > > ``` > > > Transaction with ID=42 started. > > > Compute task with ID=43 started. > > > ``` > > > > > > 3. We want to kill compute task and by mistake executing: > > > > > > cancelMxBean.cancel(42); //This will kill transaction not compute task. > > > > > > The user doesn’t have a chance to know, what type of object he is > > killing. > > > I think we should prevent this type of error by the API design. > > > > > > > > >> 5 февр. 2020 г., в 14:43, Alexey Goncharuk < > [email protected]> > > написал(а): > > >> > > >> Nikolay, > > >> > > >> > > >>> Consider copy-pasting wrong id from log to its > > >>> parameters(killing not the buggy compute task, but *VERY* important > > >>> transaction. > > >>> How users even know about this type of error with the > > >>> single method approach? > > >>> > > >>> I thought that the identifiers would never intersect (meaning that a > > >> transaction and a task would never share the same ID) > > >> > > >> I agree that change ID types for all objects would be a hard task, so > > >> probably it's worth discussing a single cancel entry on phase 3. > > > > > > > > -- Best regards, Alexei Scherbakov
