inmemory db with stm

[sidnt]

stm/tref can very well act as an inmemory concurrent datastore for our app. but there might be a few gotchas.

given situation:

• app's state is a fairly rich case class DAG, with many nodes and many leaves, starting at a single root, eg case class State(...)
• we have val inMemDb:TRef[State] = TRef.make(emptyState:State)
• we intend to modify the inMemDb in stm transactions, for managing concurrent modifications to state

to modify the state dag, as a first cut, we can call something like

def update(trS:TRef[State], p:Patch):UIO[Unit] =
  STM.atomically {
    for {
      _  <- trS.update(oldState => getNewState(oldState, p))
    } yield ()
  }

proposition: that ^ is not the best strategy to use, if we frequently need to update different subgraphs in the DAG, which have 0 nodes in common.

• are we potentially sacrificing parallelism by holding the TRef on the entire State?
• two concurrent update(...) invocations can progress in parallel in zioland, but when they come to commit, will the last one to commit go through a retry, even though it will produce the same resultant state in both the cases (because both work on entirely different subgraphs in the dag, and don't really depend on each other) ?
• if instead, we hold the TRef on apt subgraphs in the state, could we achieve a throughput greater than in the other case of holding the TRef on the entire State?