
| Key: |
CACHE-12
|
| Type: |
New Feature
|
| Status: |
Open
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
Scott Farquhar
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
--Problem--
Currently the ServletCacheAdministrator & the Caches for servlet cache are stored in the user's session & the web app's context for session scope and application scope respectively.
As such, other classes, such as EJBs, or background processes that don't run in the web context can't have access to the application scope cache, and any classes not running in the user's session cannot access their cache.
The limits OSCache's effectiveness to receive updates from external sources.
--Current WorkArounds--
- Don't use session scope, but create your own globally unique keys & use application scope. This means you can update your caches from anywhere within the web application
- Listen against other classes. Eg if using cache tags, have a parameter:
refresh="StateUtil.getNeedRefresh(key)"
and inside the tag,
StateUtil.refreshed(key)
Other applications set the refresh property. UGLY!
--Solution--
Instead of storing ServletCacheAdministrators & Caches in the context & session, store them internally inside ServletCacheAdministrator. By using a WeakHashMap, and using the session & context as keys, you can ensure that the elements get garbage collected when the sessions & contexts get collected.
You would also need to add three more methods:
public Collection getSessionCaches()
public Collection getApplicationCaches()
public Colelction getCaches()
Thus external programs would be able to loop through all the session caches & flush them as needed. This would enable database and EJB updates to flush keys as needed.
I am not sure if anyone accesses the ServletCacheAdministrators from the context directly, but if this is needed - perhaps we could have a property that determines this functionality?
I would like to go ahead and make the changes, but given the widespread effect they would have - I'd like feedback on them!
|
|
Description
|
--Problem--
Currently the ServletCacheAdministrator & the Caches for servlet cache are stored in the user's session & the web app's context for session scope and application scope respectively.
As such, other classes, such as EJBs, or background processes that don't run in the web context can't have access to the application scope cache, and any classes not running in the user's session cannot access their cache.
The limits OSCache's effectiveness to receive updates from external sources.
--Current WorkArounds--
- Don't use session scope, but create your own globally unique keys & use application scope. This means you can update your caches from anywhere within the web application
- Listen against other classes. Eg if using cache tags, have a parameter:
refresh="StateUtil.getNeedRefresh(key)"
and inside the tag,
StateUtil.refreshed(key)
Other applications set the refresh property. UGLY!
--Solution--
Instead of storing ServletCacheAdministrators & Caches in the context & session, store them internally inside ServletCacheAdministrator. By using a WeakHashMap, and using the session & context as keys, you can ensure that the elements get garbage collected when the sessions & contexts get collected.
You would also need to add three more methods:
public Collection getSessionCaches()
public Collection getApplicationCaches()
public Colelction getCaches()
Thus external programs would be able to loop through all the session caches & flush them as needed. This would enable database and EJB updates to flush keys as needed.
I am not sure if anyone accesses the ServletCacheAdministrators from the context directly, but if this is needed - perhaps we could have a property that determines this functionality?
I would like to go ahead and make the changes, but given the widespread effect they would have - I'd like feedback on them!
|
Show » |
|