Hi, I’d really like to get my handlers is a more stable state. I asked earlier for some help on my subscription catch up. That issue was cleared up, sort of.
Thank you.
However it created some new questions for me.
Greg mentioned that I should not create a new subscription on subscriptionDropped event. He says that the subscription will recover it’s self.
a) does this mean that that event is used just as a hook into the process, much like LiveProccessingStarted is? e.g. you don’t have to implement them for it to work?
b) does this mean I don’t need to track the lastprocessedposition and tell the subscription from where to start processing?
I noticed that there is no longer a start method on the subscription. If the answer to b) is no, then how would I handle this?
Thanks for the help.
R
You need to track it for when your process restarts etc
Ah, I get it, I track it for when my process restarts, not when my process is fine, but the connection to the ES is dropped.
Thanks, for the quick response.
A quick implementation question, it seems like I would need to persist the event position for every handler that handles an event, that seems like an awfully chatty process. Is there some fancy, recommended way of doing this or should i just perhaps, batch those mongo entries and persist every so often. Not that I think it would be a problem for me, but that might introduce the prospect of losing those batched entries in the case of a server failure.
thanks again,
R
Save the position in the same transaction as your other data changes.
I’m not familiar with Mongo, but I pass the db session/context/whatever to the event handler, let the handler make the changes it needs, then use the same context to save the position and commit the changes.
In most DBs, that makes it only one call, and also atomic so if the read model isn’t updated, neither is the position.
This simulates transactional messaging. Otherwise use at least once and be idempotent in your handling plus maybe batch
Yes on reconnects etc we already know it 
Great, thank you guys, trying to get ramped up very quickly and I’m dropping some balls, both of these answers are implicit in the code, I’ve just gotten confused.
Thanks again,
R
Unfortunately, mongo atomicity is at the document level. You can’t save two two documents in one acid transaction.
BUT, that won’t matter if you can write to mongo idempotently. It doesn’t really matter where you checkpoint, it’s just saving you from having to start at zero.
If you can’t be idempotent, mongo is going to be frustrating. 