We are writing Java APIs and use a cache to store session state to avoid sticky sessions.
The current application code interacts with the cache whenever it needs to read or write cache data e.g. if you are 3 calls deep a method can directly interact with the cache to get customer data with no need to state in the method signature anything about customer data. Alternatively the method can write to the cache e.g. customer data it has retrieved with no mention of customer data in the return type (e.g. the return can be void here).
I think this approach:
- Makes it very hard to control cache IO
- Hides the data that methods are using & hence makes the application harder to understand
- Makes the use of a cache intrinsic in our application, making it much harder to remove the cache at a later date.
An option we are considering is adding a Session class which interfaces to the cache. Applications would extend the Session class & pass the Session or attributes of session around. This would force methods to declare the data they use & abstract the use of the cache from the application code.
Was wondering what other peoples thoughts were on the two options,or other options?
Aucun commentaire:
Enregistrer un commentaire