« Return to Thread: Terracotta integration

Re: Terracotta integration

by richardwilko :: Rate this Message:

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

TerracottaPageStore.java

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

My blog: http://richard-wilkinson.co.uk

« Return to Thread: Terracotta integration