Credential store operations can be slow, as they generally flush the updated store to disk after every operation making multiple changes undergo many pointless flushes. We can solve this a number of different possible ways:

• Make CredentialStore use the same access pattern as KeyStore, where the user is responsible for flushing changes when they are complete, putting the user in charge of storage details (user is responsible for concurrency control)
• Make CredentialStore implement a flush() method (and hasUnflushedChanges() method) which performs the persistence step separately at a time of the user's choosing (user is responsible for concurrency control) (memory-backed stores always return false for hasUnflushedChanges()) (this is my preferred approach)
• Implement a transaction API in CredentialStore to allow concurrent non-conflicting updates with lock protection, isolation, atomicity, and consistency properties (credential store manages concurrency control via lock/transaction objects)