Retrying instead of Reconstructing Snapshot in case of "Error reading snapshot"


We, let’s say once a day, have the phenomenon the we see the following error in our logfiles:

Error reading snapshot. Reconstructing aggregate from entire event stream. Caused by: javax.persistence.PersistenceException org.hibernate.exception.GenericJDBCException: could not extract ResultSet

Since our aggregate is constructed out of hundreds and thousands of events, simply reconstructing takes quite a long
time. I have the feeling that the error has something to do with database rollbacks and
therefore simply retrying should bring the snapshot up again.

So my question: Is there a way of retrying instead of completely rebuilding a snapshot?

Hi Dirk,

That’s bothersome…and I think a correct assumption.

A simply retry on the reading of the snapshot might proof beneficial in your scenario.

I checked whether the current set up allows to retry reading a snapshot, but that’s sadly not the case as far as I can see.

What you could do, is introduce your own implementation of the [JPA/JDBC/Mongo]EventStorageEngine and override the readSnapshotData(String) function to incorporate a retry mechanism.

Alternatively, you could of course add an issue/feature request here, and let us do the work.

Or, introduce a PR introducing that functionality!

In short, it’s not available atm, but shouldn’t be to difficult to add into the framework or your personal project.

Hope this helps!



Hi Steven,

thanks for your reply. I will see what I can do!

Hi Steven,

I’m wondering whether it would be a better Idea to fail fast when we are unable to read the snapshot.
E.g. like this in the AbstractEventStore Class:

public DomainEventStream readEvents(String aggregateIdentifier) {
    Optional<DomainEventMessage<?>> optionalSnapshot;
    try {
        optionalSnapshot = storageEngine.readSnapshot(aggregateIdentifier);
    } catch (Exception | LinkageError e) {
        String message = String.format("Error reading snapshot. I stop to read the events for aggregateIdentifier %s. Caused by: %s %s",
                aggregateIdentifier, e.getClass().getName(), e.getMessage());
        throw new JdbcException(message, e);

If we have an exception due to a db rollback, a retry wouldn’t help since the transaction has already been marked as rollback only.
What do you think?

As discussed in the issue (, we have added a commit that extracts this behavior to a protected method, allowing you to override the behavior if you wish to.
See commit:

Feel free to provide feedback or comments if this doesn’t fully resolve the issue.