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
richardwilko wrote:
>
> Hi,
>
> Just because a class is instrumented (i.e. implements IClusterable) that
> doesn't mean that it is shared. It just means that it can be used in a
> shared structure if required.
>
> The way I am implementing it is to store the pages in the httpsession as
> you suggest, this has nothing to do with DiskPageStore, except that it is
> another implementation of the IPageStore interface.
>
> The reason why I had to instrument AbstractPageStore and
> TerracottaPageStore is because I am actually sharing some classes declared
> as inner classes in TerracottaPageStore.java and they have a reference to
> the parent class.
>
> I was planning to move away from having inner classes, but as the
> serialisation and deserialisation methods in AbstractPageStore are
> protected, I cant really get around it.
>
> Cheers,
>
> Richard
>
>
>
> Stefan Fußenegger wrote:
>>
>> Hi all,
>>
>> isn't DiskPageStore a singleton? So putting it into the Session (i.e.
>> making it IClusterable) would definitely be the wrong approach. I think
>> there are two possibilities:
>>
>> a) configure am additional root in TC's wicket-module that is used just
>> like the filesystem is used from DiskPageStore (let's call that "a
>> clustered filesystem" for that purpose). So every JVM would have it's
>> singelton DiskPageStore that would act as a facade to this clustered
>> filesystem.
>>
>> b) store each user's pages into the HttpSession (as it is done know)
>> using the same serialization magic that DiskPageStore uses right know.
>>
>> What do you think?
>>
>> regards
>> Stefan
>>
>>
>>
>> richardwilko wrote:
>>>
>>>
>>> Afaik you can't configure terracotta to serialise objects (its kind of
>>> the opposite of what it tries to achieve), however
>>> simply serialising the webpages doesnt work in all cases anyway (thats
>>> what my original solution did), for example when you have a reference
>>> to one page inside another you can end up with the wrong version of that
>>> referenced page.
>>>
>>>
>>> The TerracottaPageStore I am working on will take care of this, and when
>>> it is ready the only change you will need to make is adding something
>>> like this in your application class:
>>>
>>> public ISessionStore newSessionStore() {
>>> return new SecondLevelCacheSessionStore(this, new
>>> TerracottaPageStore(5, 5));
>>> }
>>>
>>> it is also posible that this could be added automatically with byte-code
>>> manipulation.
>>>
>>>
>>> John Patterson wrote:
>>>>
>>>> It seems a shame that this workaround is required to get terracotta to
>>>> be able to handle the amount of garbage created. Would be great if TC
>>>> could be configured to serialise WebPage's and their Components as
>>>> single entities. Is anything like this in the roadmap?
>>>>
>>>> JD
>>>>
>>>>
>>>
>>>
>>
>>
>
>
-----
-------
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-tp18168616p18279594.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
