Is commit position cluster wide or instance specific?

EventStoreDB
1

Hi,

I've been doing a redirect-on-POST strategy for our REST API, meaning
after a POST that leads to a write into EventStore there's a redirect
and a GET for the view, where the URL contains the commit position of
the written event(s). The GET then waits for events with that commit
position to be seen in the database before processing the query. This
gives consistent reads, cluster wide.

However, I'm beginning to suspect that there's something not quite
working with this, and the main question is whether the commit
position is consistent cluster wide or just instance wide. Meaning, if
I write an event to instance A, get commit position X, and then
redirect to a server talking to instance B and wait for X, is it
guaranteed that the same commit position X will be reported for that
event? Or can event commit positions be different between instances,
given that for example each instance has its own set of internal stats
events(is that true btw, or are those events clustered as well)?

If commit positions are not guaranteed to be reported the same by all
instances in the cluster I'll probably have to switch to using the
timestamp of the event as the syncing factor.

regards, Rickard

2

To follow-up on this, my EventStore instances return commit position
currently around 6,696,576,462, but on redirect-on-GET it might wait
for position 13,279,217,591 which is suspiciously twice what it should
be. The position comes from
WriteEventsCompleted.position().get().commitPosition() in the standard
JVM client. Any ideas what might cause this discrepancy? Feels like
it's not really a difference in instance commit position, but a "times
two" somewhere that screws things up. I checked my own code, can't
find any potential "times two" error.

/Rickard

3

Hey,

me again, I think you can ignore the below. It seems like someone had
bookmarked an old URL with an old commit position, and that was
causing most of the issues. Not all, but most.

/Rickard

4

Prepare/commit position is cluster wide. Even with scavenging enabled the original prepare/commit is kept cluster wide.