Hi Richard,
I had a thorough look on your code. I have the following remarks:
- yes, SerializedPage must be clustered and should therefore implement
IClusterable (it is already Serializable, it should therefore be okay to
change)
- I found two problems with your implementation:
1) unbind() is called during invalidation of a session. getPageStore()
will therefore result in a NPE as there is no WebRequest
2) according to the JavaDoc of DiskPageStore#removePage(SessionEntry,
String, int) ("page id to remove or -1 if the whole pagemap should be
removed") calling removePage(String, String, int) with an id of -1 should
delete all pages of a pageMap (however, that's not documented in the JavaDoc
of IPageStore!)
- I feel that all pages could be in a single HashMap (rather than using 3
levels of nested HashMaps and HashSets). I therefore implemented my own
PageStore based on your ideas to confirm my feelings (using a single HashMap
per sesison, using less Hash(Map|Set) iterations; access synchronized using
a ReentrantReadWriteLock which I think has quite good performance with TC).
Please have a look. We can probably
http://www.nabble.com/file/p18312624/MyTerracottaPageStore.java
MyTerracottaPageStore.java merge our ideas for best results!
Regards
Stefan
http://www.nabble.com/file/p18312624/MyTerracottaPageStore.java
MyTerracottaPageStore.java
richardwilko wrote:
>
> Hi again,
>
> I have put together a second version which does away with the need to
> instrument TerracottaPageStore and AbstractPageStore, but not
> AbstractPageStore$SerializedPage (no getting away from that).
>
> I have also improved the synchronisation stuff (i think, its not my strong
> point) and added a few more comments.
>
> In the end I did make the classes static inner classes; i moved all the
> code calls to the methods in AbstractPageStore, to other places.
>
> Please take a look and tell me what you think.
>
> Richard
>
> http://www.nabble.com/file/p18280052/TerracottaPageStore.java
> TerracottaPageStore.java
>
>
>
>
> richardwilko wrote:
>>
>> It does add a slight overhead but I dont think 2 extra classes wouldn't
>> be noticed.
>>
>> I can't use static inner classes because the methods in AbstractPageStore
>> aren't static.
>>
>> Your suggestion would work, with a slight modification:
>>
>> (TerracottaPageStore)
>> ((SecondLevelCacheSessionStore)Application.get().getSesssionStore()).getStore();
>>
>> So I will have a look at implementing it that way instead.
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>> Stefan Fußenegger wrote:
>>>
>>> I don't understand the problem. Is it just the visibility of those
>>> methods? If yes, TerracottaPageStore could allow public access to any
>>> protected method if needed. Or you could use static inner classes to
>>> remove this (hidden) reference and use lazy property initialization to
>>> get your hands on the current JVM's TerracottaSessionStore using:
>>>
>>> <code>
>>> private transient TerracottaSessionStore _tss;
>>>
>>> public TerracottaSessionStore getTerracottaSessionStore() {
>>> if (_tss == null) _tss = (TerracottaSesssionStore)
>>> Application.get().getSesssionStore();
>>> return _tss;
>>> }
>>> </code>
>>>
>>> However, doesn't instrumenting classes that aren't meant be shared sound
>>> like unnecessary overhead?
>>>
>>> best regards
>>> Stefan
>>>
>>>
>>>
>>>
>>
>>
>
>
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Terracotta-integration-tp18168616p18312624.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
