Hi,

My business case:
A user can add multiple IPs to subscription to scan the assets. So the
subscription can have N number of IPs.

User can add IPs in following format:
10.10.10.10,
10.10.10.12-10.10.10.100, 10.10.10.102, 10.10.10.105-10.10.11.255

So the Subscription is top level entity. Then there is a Asset group. A
user can create multiple asset group under given subscription. There can be
few  thousands asset groups under one subscription.
Asset group is a container for IPs, i.e. a user can add IPs to asset groups
which are present in his subscription and user can launch a scan using
asset groups.

Now when a user removes IPs from subscription, it needs to be removed from
the subscription as well the all asset groups. Now this must happen in a
single transaction. This is the simplest case I have.

What I meant by data processing?
- The add and remove operations are performed on these IPs using tree range
set. After performing add/remove operation I identify the exact Ids or rows
which needs to be added/updated and removed from cache. I call it as
finding delta.
Performing all mentioned operations is data processing for me. I have
created Callable/Runnable tasks to perform these operations.

My affinity key is subscription id. I submit IgniteRunnable task to remove
IPs from subscription. In normal case a subscription can have 100K to 1
Million individual IPs/IP ranges.
An asset group can have 100K to multi million individual  IPs and IP
ranges. A subscription can have 1000 to 5000 asset groups.

In side this Ignite task I perform following steps.
a) Start ignite transaction.
b)  Remove IPs from subscription in current thread.
c) Then create simple Callable/Runnable tasks to remove IPs (Data
processing) from asset groups in parallel fashion and in this task I am
also doing the cache updates. [This cache updates does not seem to be
working now as it is happening new threads.]
d) Commit the transaction.


*Now my work around to solve this problem:*
*I**n step C instead of updating the cache in callable task,  return the
delta (data needs to be updated in cache) to the thread from which ignite
transaction is started and do the cache updates. *
1) Do you think you this approach is ok or do you have any better
suggestion?

As you said, Transaction is always attached to a single thread. If you do
txStart in one thread, and then a cache operation in any other thread, this
operation will not be enlisted.
2) Is there any plan to support multithreaded cache updates inside ignite
transaction?


Thanks,
Prasad

On Fri, Jun 8, 2018 at 5:06 AM vkulichenko <valentin.kuliche...@gmail.com>
wrote:

> Prasad,
>
> What is your business use case and what do you mean by processing? Please
> describe in more detail. Are you sure you need to use the transaction here
> in the first place?
>
> -Val
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Reply via email to