you can have the the versions to MAX but this still will not result in
a session filling up because you still have the max pages, But that is i
guess
not used anymore in the SeconLevelCache. Because we don't use the
EvictPageStrategy
anymore.
I guess the only thing SecondLevelCache needs to do
PagePersistingSessionStore?
thats also a wrong name because if i would do this:
/**
* @see wicket.Application#newSessionStore()
*/
protected ISessionStore newSessionStore()
{
return new SecondLevelCacheSessionStore(new IPageStore()
{
/// default
- Align pagemaps and version management so that pages and versions are
stored in, and retrieved from the same entity.
- Change the SecondLevelCacheSessionStore so that it either saves
pages without the version manager but rather exactly as they are at
that moment or save the first version as a
On 1/9/07, Johan Compagner [EMAIL PROTECTED] wrote:
- Align pagemaps and version management so that pages and versions are
stored in, and retrieved from the same entity.
- Change the SecondLevelCacheSessionStore so that it either saves
pages without the version manager but rather exactly
4? SecondLevelCacheStore sets a IPageVersionManager, That manager is
almost completely dummy
except that it increases an page counter when the page is changed just
like
the current one does.
then we generate the versionid but nothing more. And when we try to
generate
an older page
the
what we could do is that the secondlevelcache sets the max page versions to
1
So that a page keeps 1 max page versions besides the current one.
Then one back button (that is the case for 90% of the time i guess) is done
in mem
And the overhead is only 1 changeset per page thats in mem and on
On 1/9/07, Johan Compagner [EMAIL PROTECTED] wrote:
4? SecondLevelCacheStore sets a IPageVersionManager, That manager is
almost completely dummy
except that it increases an page counter when the page is changed just
like
the current one does.
then we generate the versionid but
Just keep in mind that we should only delete the future when a
listener interface is called, not a redirect. Otherwise we will kill
the forward button. A page refresh doesn't invalidate the forward
button.
Martijn
--
Vote for Wicket at the http://www.thebeststuffintheworld.com/vote_for/wicket
exactly
We shouldn't delete any files only when the session is closed.
Why do this when the session is live? To save some space?
That looks to me like a wast of time when the session is still live and
kicking
and request is handled.
johan
On 1/9/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 1/9/07, Johan Compagner [EMAIL PROTECTED] wrote:
exactly
We shouldn't delete any files only when the session is closed.
Why do this when the session is live? To save some space?
That looks to me like a wast of time when the session is still live and
kicking
and request is handled.
Because
And if you where on version 10 and you roll backed to 6 you will never
be able to get 7 back.
This is how it should be (and was) in the first place. I applied a
little patch yesterday that actually deletes those higher version
(together with a patch that only writes a version when that
On 1/9/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 1/9/07, Johan Compagner [EMAIL PROTECTED] wrote:
exactly
We shouldn't delete any files only when the session is closed.
Why do this when the session is live? To save some space?
That looks to me like a wast of time when the session is
I created issue http://issues.apache.org/jira/browse/WICKET-201.
Eelco
i will look at it to see if i can extract the version manager from the Page
as its own global thing.
Only one thing come to my mind that could be hard.. Keeping the current
AccessStack also an option. Because the global version manager for pages
should then be integrated into the SessionStore
On 1/9/07, Johan Compagner [EMAIL PROTECTED] wrote:
i will look at it to see if i can extract the version manager from the Page
as its own global thing.
Only one thing come to my mind that could be hard.. Keeping the current
AccessStack also an option. Because the global version manager for
that stores it to a database. So the
SessionStore
itself doesn't save the pages anywhere except in a soft cache.
johan
--
View this message in context:
http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8252091
Sent from the Wicket - Dev mailing list archive
Hi,
Currently, pages and versions of pages are stored separately. Pages
are stored in IPageMaps, and each page has a IPageVersionManager. By
default (and I wonder how many users actually ever did override this)
the IPageVersionManager is UndoPageVersionManager, which keeps a list
of changes in
i dont even see the point of having an IPageVersionManager. it is tied to
Change which has an undo() method, so what other kind of manager can you
write except the undo one?
-igor
On 1/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Hi,
Currently, pages and versions of pages are stored
Exactly.
Eelco
On 1/8/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i dont even see the point of having an IPageVersionManager. it is tied to
Change which has an undo() method, so what other kind of manager can you
write except the undo one?
-igor
On 1/8/07, Eelco Hillenius [EMAIL PROTECTED]
, we could get
rid of the IPageVersionManager interface). When endVersion is called,
the changes would be flushed and saved to the pagemap and the version
manager instance should be nulled.
WDYT?
Eelco
--
View this message in context:
http://www.nabble.com/refactor-storing-pages
btw, SecondLevelCacheSessionStore seems a little fuzzy to me as a name.
it presumes someone knows what a second level cache is. what about
something a little more direct like maybe FileBackedSessionStore? not sure
i love that either, but it's maybe a little more obvious.
I don't know. It
21 matches
Mail list logo
