Johan Compagner wrote:
and i am completely not suprised that ehcache was not performing better.
How could it do that?? Where should the gain come from?
The current impl really grows directly with the hardware you have.
ehcache need to be tweaked exactly
what your system can handle. What do
I've already replaced that implementation. I can paste here one from my
local history. Beware, this might not be the right version and I don't
know ehcache very well, I'm pretty sure there are ways to do this better.
Of course i've played with the cache configuration, this is probably not
and wicket caching does exactly that (if we started caching byte[] now
instead of the pages that isn't very usefull at the moment)
What it does, it tries to cache as much as possible as long as the jvm can
handle
No default predefined size that is different for every kind of system you
deploy
Where is the serialization part?
I just see that you cache the page instance and nothing more.
Thats a bit wrong. Because the SessionPageKey stores a version number
But the page instance increments that version number everytime. So you can't
assume
that getPage() will return the one with the
I looked at pages second level cache implementation in 1.3 and wonder
why not to use ehcache instead? It's much more intelligent, configurable
and performant. For example, it can have part of cache in memory while
swapping less frequently used pages on the disk.
--
Andrew Klochkov
On 2/14/07, Andrew Klochkov [EMAIL PROTECTED] wrote:
I looked at pages second level cache implementation in 1.3 and wonder
why not to use ehcache instead?
Exactly what I have advocated, and which is why it is had the name
'second level cache'. However, I don't think it should be the default,
I've tried writing a IPageStore using ehcache today, the performance
wasn't better than what we already have.
And Wicket second level session store is not really a cache, it's works
differently.
-Matej
Eelco Hillenius wrote:
On 2/14/07, Andrew Klochkov [EMAIL PROTECTED] wrote:
I looked at
On 2/14/07, Matej Knopp [EMAIL PROTECTED] wrote:
I've tried writing a IPageStore using ehcache today
Cool. Maybe you could paste the code into a blog or WIKI page?
Eelco
-
Take Surveys. Earn Cash. Influence the Future of
Its EXACTLY a cache
What isn't a cache is ehcache
At least not in my point of view
A cache is something you cache something as good as you can but it can be
gone at anytime.
ehcache is not a cache. Its a in memory predefined size list. where some can
drop of and others not
thats not caching.
But cache is for caching things that are expensive to get, but when they
are evicted from cache, they can be restored. When you remove wicket
page (or better said page version) for wicket 2nd level store, it can
not be restored.
As for performance, the gain could be in finer grained
Everything can be restored. Because everything is on disk.
yes but synching should be looked at. i think i go with jonathans idea that
i already was thinking of.
use a concurrent hashmap and then one entry is a list for one session.
then concurrency should be almost gone between sessions.
johan
i wonder if it wouldn't pay to stop and refactor this a little.
besides repackaging, it seems like there is really a sessionstore
which stores sessions and a pagestore which stores pages for
a given session (that independently synchronized sublist).
i'm not sure that's the best thing, but i am
no there is not a page store per session
There is only one sessionstore and one pagestore per application.
what should be refactored a bit is the actual saving
Previously it was really a simple thing that serialized the page and saved
to disk
Now those 2 operations are really divided and a
On 2/14/07, Johan Compagner [EMAIL PROTECTED] wrote:
Its EXACTLY a cache
What isn't a cache is ehcache
At least not in my point of view
A cache is something you cache something as good as you can but it can be
gone at anytime.
ehcache is not a cache. Its a in memory predefined size list.
right. i wasn't talking about instances. only interfaces and method
calls. conceptually, if you have a session that is a store of pages
(the page map). you can ask the session for an interface that gives
you pages. how that's implemented is probably as you suggest.
although decoupling these
On 2/14/07, Johan Compagner [EMAIL PROTECTED] wrote:
no there is not a page store per session
There is only one sessionstore and one pagestore per application.
Yeah. My first implementation was actually per session, so that's
where we came from. That didn't work at it wasn't possible to support
right. i wasn't talking about instances. only interfaces and method
calls. conceptually, if you have a session that is a store of pages
(the page map). you can ask the session for an interface that gives
you pages.
But then you need to have a session first, and where to get that from
is
ok. if you say so. i don't know the details here.
Eelco Hillenius wrote:
right. i wasn't talking about instances. only interfaces and method
calls. conceptually, if you have a session that is a store of pages
(the page map). you can ask the session for an interface that gives
you
18 matches
Mail list logo
