Scribd
Upload
9 views2 pages

Memory Checkpoint

Uploaded by

Greg Young
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
9 views2 pages

Memory Checkpoint

Uploaded by

Greg Young
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

Memory Checkpoint

A Memory Checkpoint is an implementation of the checkpoint pattern that


resides in memory. It is not durable and will only operate while the system is
up and running.
A Memory Checkpoint while not being durable is the simplest of the checkpoint
implementations and is also the most performant. There are often cases where
durability is not important for varying reasons as example a test system or the
thing associated to the checkpoint is intended to be rebuilt on a restart.
There is a related pattern here that can be used which is a shared memory
checkpoint if running on a clustered operating system or having multiple con-
sumers. The only difference is that it is stored in shared memory as opposed to
regular memory. A shared memory checkpoint might also be durable but this is
environment specific.
Like other Checkpoints a Memory Checkpoint should support setting and re-
trieving the checkpoint location.
public class InMemoryCheckpoint : ICheckpoint {
private long _last;

public InMemoryCheckpoint(long initValue = 0) {


_last = initValue;
}

public void Write(long checkpoint) {


Interlocked.Exchange(ref _last, checkpoint);
}

public long Read() {


return Interlocked.Read(ref _lastFlushed);
}

public void Flush() {


Interlocked.Exchange(ref _lastFlushed, last);
}

public void Close(bool flush) {


if (flush)
Flush();
}
}
The example is from EventStore’s codebase and modified slightly to make it
simpler. You can find the original in the codebase [1].
This InMemoryCheckPoint could also obviously operate in a similar way via

1
shared memory etc. Do note the care which has been taken in the implementation
around threading and the use of interLocked operations. It is not uncommon
that you have multiple threads operating on the same checkpoint.
When you have multiple threads operating on the same InMemoryCheckpoint you
can quite easily run into threading issues associated with how it interacts. There
is however simultaneously a cost associated to making an InMemoryCheckpoint
capable of supporting many concurrent callers.
In many codebases you will see two implementations. One which is focused on
dealing with a single subscriber (and is optimized for it) and another which can
safely support many subscribers.
[1] https://github.com/EventStore/EventStore/blob/master/src/EventStore.Core/TransactionLog/Checkpoint/I

You might also like