VUS Design Issues - illyfrancis/scribble GitHub Wiki

multiple threads access to the same persistence?

Problem

Assume there are two threads both start working with the same transaction Id. Also assume:

  • The transaction Id is unknown to the db
  • Both threads see that the transaction Id is unknown (after querying the db) hence both start to create a new VUS
  • When one thread persists the new states (new VUS, TxnId, and Transaction nodes) it succeed
  • When the other thread persists the new states, what should happen?
    1. If VUS, TxnId and Transaction nodes were defined with unique indexes, the second writes would/should fail
    • If no unique index, the write operations may still be successful and there's a parallel universe of the same TxnId

Either cases are not desirable, because:

  1. if the second thread fails to persists, the transaction it tried to process is lost unless there's more complex error handling is considered, which is not trivial and should be avoided
  2. if there are parallel VUS, TxnId etc, it breaks the fundamental assumptions with regards to transaction processing. The foundation of the process assumes there's one and only one TxnId node not multiple.

Challenges

  • How to simulate above problem? Can a test be written for it?

Resolution?

None yet.

Can the messages be routed according to its related transactionId? So basic idea is to force the processing of the messages with the same transaction id in the same thread to avoid above situation.

What about a solution with the use of STM?

Don't know much about STM to consider at this point.