Over 1000 gaps triggers Oracle "1000 elements in list" limitation

The number of gaps in the events processed by a tracking event processor occasionally exceeds 1000, which triggers the Oracle limitation of maximum number of elements in an IN-clause. We would like a work-around in Axon Framework to handle this situation by splitting the IN-clause in as many IN-clauses as needed, concatenated by OR’s. We think the following code in org.axonframework.eventsourcing.eventstore.jdbc.JdbcEventStorageEngine (version 4.0.3) would do this:

    protected PreparedStatement readEventDataAxon(Connection connection, TrackingToken lastToken,
        int batchSize) throws SQLException {
        isTrue(lastToken == null || lastToken instanceof GapAwareTrackingToken,
            () -> format("Token [%s] is of the wrong type", lastToken));
        GapAwareTrackingToken previousToken = (GapAwareTrackingToken) lastToken;
        String sql = "SELECT " + trackedEventFields() + " FROM " + schema.domainEventTable() +
            " WHERE (" + schema.globalIndexColumn() + " > ? AND " + schema.globalIndexColumn() + " <= ?) ";
        List<Long> gaps;
        if (previousToken != null) {
            gaps = new ArrayList<>(previousToken.getGaps());
            if (!gaps.isEmpty()) {
//                sql += " OR " + schema.globalIndexColumn() + " IN (" +
//                    String.join(",", Collections.nCopies(gaps.size(), "?")) + ") ";
                final AtomicInteger counter = new AtomicInteger(0);
                sql += " OR " + Collections
                    .nCopies(gaps.size(), "?")
                    .stream()
                    .collect(Collectors.groupingBy(it -> counter.getAndIncrement() / 1000))
                    .values()
                    .stream()
                    .map(placeholders -> placeholders.stream().collect(Collectors.joining(", ", schema.globalIndexColumn() + " IN (", ")")))
                    .collect(Collectors.joining(" OR "));
            }
        } else {
            gaps = Collections.emptyList();
        }
        sql += "ORDER BY " + schema.globalIndexColumn() + " ASC";
        PreparedStatement preparedStatement = connection.prepareStatement(sql);
        long globalIndex = previousToken == null ? -1 : previousToken.getIndex();
        preparedStatement.setLong(1, globalIndex);
        preparedStatement.setLong(2, globalIndex + batchSize);
        for (int i = 0; i < gaps.size(); i++) {
            preparedStatement.setLong(i + 3, gaps.get(i));
        }
        return preparedStatement;
    }

The same solution would be applicable to version 3.x.

[ericjanmalotaux]

Thanks @smcvb, that’s exactly what we are doing. At the same time we wanted to be good open source community citizens and offer our solution to whoever would benefit from it.

[abuijze]

This issue has been the subject of discussions several times, here. On one hand, we do see there are some optimizations that could be done in the framework. However, we feel that the root cause is in the occurrence of the high number of gaps, in the first place. Configuring the database to work with dedicated sequences for the Domain Event Entry table is a solution that targets the root cause. Ultimately, there is always the possibility to tweak the exact SQL statements performed by the Storage Engine to resolve database-specific issues that may arise.

Since there are enough alternatives, we have decided not to build anything specific into Axon to resolve this issue.