Feature/613 lock entities #690
Conversation
ndr-brt
force-pushed
the
feature/613-lock-entities
branch
4 times, most recently
from
c8641fa to
30b131a
Compare
ndr-brt
requested review from
ronjaquensel,
paullatzelsperger and
jimmarino
and removed request for
ronjaquensel
| var contractNegotiation = negotiationStore.find(negotiation.getId()); | ||
| if (throwable == null) { | ||
| negotiation.transitionOffered(); | ||
| negotiationStore.save(negotiation); | ||
| observable.invokeForEach(l -> l.providerOffered(negotiation)); | ||
| contractNegotiation.transitionOffered(); |
There was a problem hiding this comment.
I think contractNegotiation should be checked for null here (like in the TransferProcessManagerImpl), otherwise might lead to a NullPointerException. Same for other methods in both *NegotiationManagers.
There was a problem hiding this comment.
Yes, you're right, I didn't do that because it was already done in #642, I didn't want to replicate too much logic here since I'll have enough conflicts to fix when it will be the time for rebase
There was a problem hiding this comment.
Makes sense, I missed that it was done on the other branch.
ndr-brt
force-pushed
the
feature/613-lock-entities
branch
10 times, most recently
from
80a9241 to
0d9b2d1
Compare
|
With @paullatzelsperger agreed that the lock mechanism should be handled with the lease on cosmos db, so that an entity is leased when it's fetched with |
ndr-brt
force-pushed
the
feature/613-lock-entities
branch
5 times, most recently
from
ffef89b to
5dd8bf2
Compare
ndr-brt
force-pushed
the
feature/613-lock-entities
branch
from
5dd8bf2 to
4830726
Compare
|
Replaced by #710 |
Fix #613
Context
Currently, on the state machine loop, when an entity is processed asynchronously, it has to be put in an intermediate state to avoid the loop to fetch and process it again before the async operation completes.
What brings
The entities (
TransferProcessandContractNegotiation) can be locked.A locked entity cannot be fetch by the
nextForStatequery, it can only be fetch by id.An entity gets unlocked on every state transition, so when a locked entity is fetched by id after the completion of an async operation and transitioned to another state, it gets unlocked automatically.
This will help the implementation of #416 , since an entity could be considered "stale" when it's locked for a certain amount of time.
There's also a refactoring, I didn't get why in the managers the stores were injected at
start, now they are built into the managers through the builders.