Add support for a STRICT_REPLACEMENT option in TransactionalIndexedCollection about cqengine HOT 6 CLOSED

Have you read this documentation? https://github.com/npgall/cqengine/blob/master/documentation/TransactionIsolation.md

from cqengine.

Yes.

Let's say I wanted to store a single integer as an atomic counter.

The initial value is 4, and a couple threads are concurrently incrementing it.

{4}
t1: update(4, 5) -> {5}
t1: update(5, 6) -> {6}
t2: update(4, 5) -> {5, 6} (BAD STATE)

from cqengine.

I see.

Maybe it's not clear from the documentation, but atomic object replacement here means if an object is contained in the collection, it can be swapped for another object, such that reading threads will either see the old object, or the new object, but not both, and not neither. The atomic aspect is from the perspective of the reading threads, not the writing threads.

There is no CAS operation. Basically, the behavior is intentionally similar to transaction isolation in databases. In databases, if you have a transaction comprised of a DELETE statement followed by an INSERT statement, and the DELETE statement does not match any rows, then it does not abort the transaction, and INSERT will still be performed.

Maybe it would be possible to extend TransactionalIndexedCollection with support for CAS operations. Can you give me a good use case for it? Implementing an atomic counter isn't really compelling enough as we already have AtomicInteger for that. But I guess above is just an example and you have another use case?

Incidentally, note that TransactionalIndexedCollection will actually serialize all of your calls to the update() method above. Currently the MVCC mechanism prevents concurrent writes. So technically if you wanted to achieve CAS semantics, you could synchronize all of your writes externally outside of CQEngine, and before you call update(), your could check if the first object is contained :)

from cqengine.

Well, an atomic counter isn't compelling in and of itself (although, it's a pretty basic atomic operation). But rather, we may want to atomically update some fields of a larger object. For example, a BankAccount object might have many fields. One really important field to update atomically is balance. And it doesn't have to be numeric. There might be an array field emails and we want to make sure that concurrent appends don't end with a race.

More generally, it's useful for DB operations to grab a write lock, read some data, write some data based off of the reads, and then release the lock.

from cqengine.

Okay I can see how it might be useful.

I think I will add support for it, by allowing the client to supply a query option to the update methods such as: queryOptions(enableFlags(TransactionalIndexedCollection.STRICT_REPLACEMENT))

If this is supplied, then the update method will validate that the objects to be replaced actually are stored in the collection. If any are not, it will not modify the collection and the update method will return false.

from cqengine.

Done. This is implemented and will be included in the next release. Thanks for the suggestion!

from cqengine.