To avoid filling logs with with "expired" transactions we provide implementations of the ExpiryScanner interface which run periodically (the default is every 12 hours) and if the same entry is present on consecutive scans then it is moved to a different part of the store (we keep a copy to avoid mistakes) where it is no longer eligible for recovery. This can happen if a resource cannot be contacted and/or the resource does not have a record of the transaction which can happen if it crashed after the TM wrote its log but before the resource could - this later case should now be a rare occurrence since we fixed JBTM-860 (use XAResourceWrapper metadata for assume complete). Because the operation of moving logs is potentially dangerous the scanners are disabled by default. The change introduced by JBTM-3801 adds two new scanners (AdvancedAtomicActionExpiryScanner and AdvancedAtomicActionPurgeExpiryScanner) which operate based on the time the log was created and if an entry is found that has remained in the log for longer than the default scan period then it becomes eligible for expiry (the AdvancedAtomicActionExpiryScanner moves the entry whereas the AdvancedAtomicActionPurgeExpiryScanner deletes it). These scanners avoid the need to wait for a second recovery pass which can be of benefit for short-lived applications. Warning, expiring logs based on creation time can be an issue if the system is not brought back up after a crash within the ExpiryScanner scan interval since a log will be immediately expired before there is an attempt to recover the log because the scanners run before a recovery cycle.