Jans Lock revoked token list integrity and auto recovery
The are few challenges related to revocation list implementation in multi server environment. This design is address to resolve cluster concurrent data updates in DB. Also it provides method to self recovery on node failure.
As startup node should find stalled entries in jansNode (lastUdpate happened more than 1 minute ago) table and try to attempt it lock with lockKey attribute. If after entry lockKey remain the same it means that server successfully locked this entry. If there is no stalled entries in this table it should add new entry to DB.
In this part we never remove records from DB jansNode. Also for any hanged JansAuth node we assign it successor to resume it work.
Another challenge is to maintain cluster token list. Implementation should provide way to update this list without data loss and concurrent data locks. Also each token mapping from token list should correctly identify token entry in DB. Proposed solution is based on block preallocation. This means that cluster node update only specific entry in DB on token status change. As result each node data update can be done at any time without delays.
In this solution even after server breakdown new node instance should continue already allocated block maintain.
Also server not remove entries from DB. If block is not in use any server can reuse it again. If there is no free block node can add new entry to DB to allocate new block.
This model allow to combine smaller pieces of token revocation list on global list generation. Server should join blocks based on jansId order. After that it can send it to cache with extirpation 30 seconds or store in another table in DB to allow reuse by other parts.
