search

sageserpent-open / plutonium

CQRS providing bitemporal object modelling for Java POJOs and Scala too.
MIT License
5 stars 0 forks source link

Persistence - support concurrent usage via Multiple Clients #21

Closed sageserpent-open closed 8 years ago

sageserpent-open commented 8 years ago

This was broken out of issue #14.

  1. The concurrency test needs to actually force race conditions.
  2. It should fail when they occur.
  3. Redis transactions / scripting or something needs to be added to make these tests pass.
sageserpent-open commented 8 years ago

Try and bring this in for sprint #5, now that issue #23 is near to closing. Hopefully this is a simple case of adding a watch into the transaction. I have already tried doing this in the context of RediScala, but I'm not convinced that transactions were working in the first place with that library. From the progress of issue #23, I can see that transactions are working, so it's worth revisiting this approach.

sageserpent-open commented 8 years ago

An old friend revisits - it looks like one can't directly convert the RxJava observable resulting from an 'exec' call in Lettuce to an RxScala observable - have to treat as via the Java API. All the other Lettuce Java observables seem to work OK, though...

sageserpent-open commented 8 years ago

Not sure about this previous comment; the problem might be due to some other issue, which is now lost in a heap of variations trying to get Redis watching to work with the reactive API.

I'm going to put this issue on hold and drop it from the sprint, it's become a time sink...

sageserpent-open commented 8 years ago

Have done some follow-on work on this - turned out that after revisiting the Scala worksheet with some simple transaction code and using the Redis monitoring facility, the code wasn't running the updates in the Redis transaction. This has been fixed and propagated into the Redis-based world implementation, which now passes the concurrency test with 68% detection of concurrent revisions, 29% races causing precondition failures and 3% of cases that didn't collide.

sageserpent-open commented 8 years ago

However, the existing concurrency test only checks for concurrent revisions racing against each other - need to generalise the test to include queries being executed concurrently with revisions. There is currently no protection of the query code against data races, so this test should fail initially.

sageserpent-open commented 8 years ago

Test provided and both of the world implementations have been cut over to pass it.

sageserpent-open commented 8 years ago

NOTE: have found out that Redis transactions need to have at least one command in the transaction body in order to distinguish between a transaction aborted due to a watch detecting concurrent modification and the usual path of successful execution.