| Key: |
CACHE-175
|
| Type: |
Bug
|
| Status: |
Open
|
| Priority: |
Minor
|
| Assignee: |
Unassigned
|
| Reporter: |
Peter Bridge
|
| Votes: |
0
|
| Watchers: |
1
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Environment:
|
single threaded test
JDK 1.4.2
single threaded test
JDK 1.4.2
|
|
|
If I flush my cache, add a new item and then try to read that item straight away, then sometimes (70%?) I can get a NeedsRefreshException.
This is because in Cache.isFlushed(...) the flushDateTime is the same as the lastUpdate timestamp.
I guess with JDK50 you can use the high resolution timer to fix this? or for now maybe subtract 1ms from the flush time to ensure it is always seen as being in the past...
Kind Regards,
Peter
PS any chance that the NeedsRefreshException design approach will be dropped? I just started evaluating OSCache today and this approach looks pretty ugly IMO.
|
|
Description
|
If I flush my cache, add a new item and then try to read that item straight away, then sometimes (70%?) I can get a NeedsRefreshException.
This is because in Cache.isFlushed(...) the flushDateTime is the same as the lastUpdate timestamp.
I guess with JDK50 you can use the high resolution timer to fix this? or for now maybe subtract 1ms from the flush time to ensure it is always seen as being in the past...
Kind Regards,
Peter
PS any chance that the NeedsRefreshException design approach will be dropped? I just started evaluating OSCache today and this approach looks pretty ugly IMO. |
Show » |
| There are no comments yet on this issue.
|
|
Flush then add, then read, can result in NeedsRefreshException