i'm not sure i understand completely. so it's
PageMap -> SecondLevelCacheSessionStore (with soft references?) ->
FilePageStore ?
I don't know about the PageMap -> Store part... currently the PageMap
goes in the store.
The second level cache bit came from the idea that you would have a
first l
t; is. It caches
> the pages and only the FilePageStore (IPageStore) stores it to a dir.
> But that can also be a implementation that stores it to a database. So the
> SessionStore
> itself doesn't save the pages anywhere except in a soft cache.
>
> johan
>
>
--
V
That sucks. So maybe we can't just save the changes when working with
the slc store. What we still can try is optimize how often is saved.
Or customize serialization :)
Actually I am curious how well xstream performs here compared to
normal serialization.
Eelco
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 pa
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 (el
I created issue http://issues.apache.org/jira/browse/WICKET-201.
Eelco
On 1/9/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> > 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
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 sessi
> 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 versi
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
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:
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
Wi
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 v
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 disk.
>
> 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
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 ex
On 1/9/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
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.
why not rename IPageMap to IPageStore and just chain these. you can have
SessionPageStore(SoftRefPageStore(DiskPageStore))
-igor
On 1/9/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> PagePersistingSessionStore?
thats also a wrong name because if i would do this:
/**
* @see wicket
- 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 f
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 emp
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.
no that is not ob
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 is
; stored in a database system.
>
> Eelco
>
>
--
View this message in context:
http://www.nabble.com/refactor-storing-pages-and-versions-tf2943670.html#a8233508
Sent from the Wicket - Dev mailing list archive at Nabble.com.
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 doe
. This would be my choice as it is more efficient
>>> in especially storing it, and storing is the part having a greater
>>> impact than retrieving.
>>> - Page should only use a temporary instance of IPageVersionManager and
>>> the newVersionManager method could be private imo as I don't see much
>>> use now users being able to provide their own (in fact, 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-and-versions-tf2943670.html#a8232968
Sent from the Wicket - Dev mailing list archive at Nabble.com.
ld only use a temporary instance of IPageVersionManager and
>> the newVersionManager method could be private imo as I don't see much
>> use now users being able to provide their own (in fact, we could get
>> rid of the IPageVersionManager interface). When endVersion is called,
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
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 sepa
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 th
29 matches
Mail list logo
