EJSarge (7) [Avatar] Offline
#1
I don't believe this question is covered within the scope of the book as written so far. However, I am very interested in the answer and believe others would be too so I offer it up as something to cover as appropriate.

How do I maintain a safe multi-threaded view of what the current state of an entity is when the entity is immutable?

While I can use the techniques presented thus far to create a copy of the entity with some change I now need to put that changed entity somewhere. If some other thread is also making a change then I need to co-ordinate that somehow.

Using the Trade example from the blog, how would I manage it so that, while the Trade is being processed by something long-running, another client thread can query or update the status of that Trade.
Debasish Ghosh (113) [Avatar] Offline
#2
You are right. We have not yet discussed this aspect till now. We will be doing that when we move on to discussing the reactive part of the domain model.

But just to give you a heads up, one of the ways that we will be discussing to achieve this is using the Memory Image architecture as described by Martin Fowler in http://martinfowler.com/bliki/MemoryImage.html. Of course this requires EventSourcing, which will be another topic that we will discuss.

These related technologies are implemented by Akka persistence. Martin Krasser, the creator of Akka persistence has a series of blog posts starting http://krasserm.blogspot.in/2011/11/building-event-sourced-web-application.html that discusses the core techniques.

Thanks.
DG2 (1) [Avatar] Offline
#3
There's a small problem with the link you provided. This should work: http://martinfowler.com/bliki/MemoryImage.html
EJSarge (7) [Avatar] Offline
#4
Hi Debashish,
I note that Martin Krasser's implementation uses Software Transactional Memory (STM) to handle the update.

I was reminded that I was seeing references to STM being deprecated in various places and recently came across these two linked posts in the Akka mailing list:
  • http://www.infoq.com/news/2010/05/STM-Dropped

  • http://joeduffyblog.com/2010/01/03/a-brief-retrospective-on-transactional-memory/


  • Joe Duffy's retrospective is especially interesting.

    In my case, I worked around this by implementing the state update using compare and set for the entire aggregate root reference. As it happens, I did that by CASing to the database but it would work equally well in memory.