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-tp18168616p18278655.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
