The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Steve Friend (3) [Avatar] Offline
#1
Hi there, I'm not sure how lively this forum is, but I thought I'd ask a question about the Transactional Service as outlined from pp37 onwards. Specifically, looking at figure 2.8 I'm struggling to see how you could implement a transaction for this series of events.

Possibly it's just the example that's been chosen, but in step 2.3 an order is placed with an external system. If step 2.4 were to fail how would 2.3 be rolled back? I can see all sorts of complexity here, which could possibly be managed by a Saga, but I'm not sure that could be called a 'transaction'.

Any thoughts?
Cheers,
Steve
arnonrgo (62) [Avatar] Offline
#2
Re: Transactional Service - really?
Hi Steve
This pattern is not about an overall transaction between the external source and the service. Rather it is about handling a transaction inside the service between getting the input and acting on it. Thus in this case if something "bad" happens while handling the order the request will go back to the queue and will still be handled when the service is up again.

If the service can't fulfill the order then it would send out an event (or message or return a message etc.) that it can't but that would still constitute a valid transaction.

The failure might fail the whole business process, which, as you've said is better handled by a saga (or via orchestration which the book doesn't describe yet).
A cross-service transaction is indeed a problem and that's described in an anti-pattern by that name

Regarding the specific example - I have to say I had a transactional transport in mind (specifically queues) when I wrote that, and I see that while it is implied in the text ("This means that if you don’t handle the message (e.g. due to a crash) no message leaves the service") it isn't really explained. Thanks for pointing that out

Arnon