|
15 | 15 | logger = logging.getLogger(__name__) |
16 | 16 |
|
17 | 17 | class PersistedTokenCache(msal.SerializableTokenCache): |
18 | | - """A token cache using given persistence layer, coordinated by a file lock.""" |
| 18 | + """A token cache backed by a persistence layer, coordinated by a file lock, |
| 19 | + to sustain a certain level of multi-process concurrency for a desktop app. |
| 20 | +
|
| 21 | + The scenario is that multiple instances of same desktop app |
| 22 | + (or even multiple different apps) |
| 23 | + create their own ``PersistedTokenCache`` instances, |
| 24 | + which are all backed by the same token cache file on disk |
| 25 | + (known as a persistence). The goal is to have Single Sign On (SSO). |
| 26 | +
|
| 27 | + Each instance of ``PersistedTokenCache`` holds a snapshot of the token cache |
| 28 | + in memory. |
| 29 | + Each :func:`~find` call will |
| 30 | + automatically reload token cache from the persistence when necessary, |
| 31 | + so that it will have fresh data. |
| 32 | + Each :func:`~modify` call will |
| 33 | + automatically reload token cache from the persistence when necessary, |
| 34 | + so that new writes will be appended on top of latest token cache data, |
| 35 | + and then the new data will be immediately flushed back to the persistence. |
| 36 | +
|
| 37 | + Note: :func:`~deserialize` and :func:`~serialize` remain the same |
| 38 | + as their counterparts in the parent class ``msal.SerializableTokenCache``. |
| 39 | + In other words, they do not have the "reload from persistence if necessary" |
| 40 | + nor the "flush back to persistence" behavior. |
| 41 | + """ |
19 | 42 |
|
20 | 43 | def __init__(self, persistence, lock_location=None): |
21 | 44 | super(PersistedTokenCache, self).__init__() |
|
0 commit comments