yes, this was part of the 4.2 release. The change involves the timing in which the token is being updated. Originally, the process involved extending the token (thus obtaining a write lock) first and then updating it at the end of the batch with the new token position.
Now, if there is a Transaction Manager configured, the process is slightly different. The token is updated to the new state immediately, then the events are handled, and the transaction is committed. If processing the events took more than 50% of the token claim time-out, another update is executed to extend the claim on the token. This means that, in the vast majority of cases, only a single round-trip is needed to update the tokens, rather than 2.
However, if there is no inactivity, there will still round-trips to extend the claim on the token. Prior to 4.2, this was hard-coded to 1 second. Since 4.2, this is configurable (defaulting to 1 second) using the “TrackingEventProcessorConfiguration.andEventAvailabilityTimeout” method. Make sure this timeout and the “claimTimeout” on the Jpa/JdbcTokenStore are in balance. You want to be able to perform approximately 2 roundtrips to the token store before the claims time out, to make sure Tokens don’t get “stolen” too often.
Hope that makes sense.