Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question

GigaSpace.clear() and maximum number of objects

The method GigaSpace.clear() does not accept a maximum number of objects to be deleted. This is different to all other methods which update or delete objects. A a result, it is not possible to use the operation clear() when there is a risk that it will affect so many objects in a single transaction that the underlying RDBMS will have a problem with too large transaction.

Is it a design decision to not provide a method clean() with a parameter for a maximum number of affected objects, or is it just missing and you may add such method?

asked 2018-01-29 08:10:22 -0500

Alexey Serdyuk gravatar image
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

It's a design decision, though it's definitely doable.

We categorize query-related methods as follows:

  1. Methods which return single entry (e.g. read, take)
  2. Methods which return multiple entries (e.g. readMultiple, takeMultiple)
  3. Methods which affect multiple entries but don't return them (e.g. count, clear, change)

Methods from the 2nd category have an argument which limits the maximum results to protect the client from running out of memory. Methods from the 3rd category don't need that protection, hence don't have that argument. The underlying RDBMS (if any) was not part of the considerations for that API decision.

Adding such an argument will also affect execution efficiency on a partitioned cluster - takeMultiple executes sequentially to make sure it doesn't exceed the specified limit (e.g. takeMultiple(100) will execute on the first node. Suppose it removed 20 entries, it would then execute on the next node with max=80, and so on). Clear, on the other hand, would execute concurrently on all partitions, since there's no limit. Adding an override method with a limit would force that override to execute sequentially instead of concurrently. It's not horrible, but not ideal, and we've never encountered the need to do it so far.

Regarding your note on the underlying RDBMS having a problem with too large transaction - if you intend to break the clear into batches, each of them in a separate transaction to protect the DB, I'd argue that the transaction is not really helpful, since it's multiple transactions and not a single one, so there's no ACID, and you might as well do it in a single clear with no limit and no transaction.

Another option is to use takeMultiple instead, which does have a limit. It's not as efficient because it returns the removed entries, but this can be reduced by using projection.

If you still think this feature is important, you're welcome to submit a feature request thru our public Jira - https://insightedge.atlassian.net/bro...

answered 2018-02-01 10:30:30 -0500

niv gravatar image
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2018-01-29 08:10:22 -0500

Seen: 139 times

Last updated: Feb 01 '18