es or quickstart it's easy and a lot more efficient
> than trying to think of things beforehand.
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oyhttp://www.ri.fi/ >
>
> ------------------
On Fri, 16 Nov 2007, saenz wrote:
> In fact, I can't tell whether the IPageMap or the IPageVersionManager (or
> both) are used to serialize old versions of Page instances. I would assume
> that IPageVersionManager is where this is implemented, but I can't be sure.
> The ISessionStore interface has
And then to be even more clear
when you do the code below that eelco has given you as an example
the back button wil NOT work anymore.
johan
On Nov 17, 2007 2:23 AM, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > You could also explain some of the details of what should be returned by
> our
>
> You could also explain some of the details of what should be returned by our
> override of WebApplication.newSessionStore(). The javadoc for this method
> reads "typically not something clients reimplement" so I assume we really
> need to know what we're doing if we override this method.
This in
;[EMAIL PROTECTED]> wrote:
> >
> >>
> >> Hi Johan,
> >>
> >> Would you mind being a little bit more specific? Or you may feel free to
> >> point me to the documentation that I should read.
> >>
> >>
> >>
> >>
t;> Would you mind being a little bit more specific? Or you may feel free to
>> point me to the documentation that I should read.
>>
>>
>>
>> Johan Compagner wrote:
>> >
>> > Application
>> > *protected* *abstract* ISessionStore newSessi
on that I should read.
>
>
>
> Johan Compagner wrote:
> >
> > Application
> > *protected* *abstract* ISessionStore newSessionStore();
> >
>
> --
> View this message in context:
> http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006
ustered), and how applications should handle
the back button on the browser?
Thanks.
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13804104
Sent from the Wicket - User mailing list archive at Nabble.com.
-
w.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13804076
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-
pes of load balancing strategies
> > >> besides
> > >> sticky sessions are all flawed, and that it only makes sense to use
> > >> sticky
> > >> sessions? Plea
mproved replicated page store in
> > Wicket 1.3 RC or will that be a 2.0 feature?
> >
> > Also -- if page serialization is disabled, what happens when the user
> hits
> > the back button?
> > --
> > View this message in contex
cket to save pages to a shared drive
> >
>
> Thanks Igor. Are you saying that we can configure Wicket to store old
> versions of Pages in the HttpSessionStore (in memory)? If so, how do we
> configure this?
> --
> View this message in context:
> http://www.nabble.com/Disa
> wrote:
>
> Also, can someone answer this other question I asked?
>
>
> saenz wrote:
> >
> >> Also -- if page serialization is disabled, what happens when the user
> >> hits
> >> the back button?
> >
>
> --
> View this message in
Also, can someone answer this other question I asked?
saenz wrote:
>
>> Also -- if page serialization is disabled, what happens when the user
>> hits
>> the back button?
>
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pag
we
configure this?
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13800373
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubsc
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13796998
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Nov 16, 2007 10:33 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> you can still cluster 1.3.1 easily. either use httpsessionstore or
> tell wicket to save pages to a shared drive
Or use that project Matej is working on. It works.
Eelco
-
sticky sessions are all flawed, and that it only makes sense to use sticky
> sessions? Please correct my understanding.
>
> If sticky sessions are the only recommended way to do load balancing, then
> what is the reason to support replication of session state across multiple
> nodes in a cluster?
sessions are the only recommended way to do load balancing, then
> what is the reason to support replication of session state across multiple
> nodes in a cluster?
failover
-igor
>
> - Lu
> --
> View this message in context:
> http://www.nabble.com/Disabling-serialization-s
recommended way to do load balancing, then
what is the reason to support replication of session state across multiple
nodes in a cluster?
- Lu
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13796491
Sent from the W
On Nov 15, 2007 11:22 PM, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > What is the recommended deployment model to support back-button usage
> via
> > undoable changes and disk-based serialized storage with Wicket? Is it
> only
> > possible using a load balancer configured to be "sticky" (keep s
e?
>
> Also -- if page serialization is disabled, what happens when the user hits
> the back button?
> --
> View this message in context:
> http://www.nabble.com/Disabling-serialization-storage-of-pages-in-s
or will that be a 2.0 feature?
Also -- if page serialization is disabled, what happens when the user hits
the back button?
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13797991
Sent from the Wicket - User mailing list
> > Is the page storage on node1 is replicated to other nodes? If not, what is
> > the behavior of Wicket running on node2?
> >
>
> --
> View this message in context:
> http://www.nabble.com/Disabling-serializ
all flawed, and that it only makes sense to use
> >> sticky
> >> sessions? Please correct my understanding.
> >>
> >> If sticky sessions are the only recommended way to do load balancing,
> >> then
recommended way to do load balancing,
>> then
>> what is the reason to support replication of session state across
>> multiple
>> nodes in a cluster?
>>
>> - Lu
>> --
>> View this message in context:
>> http://www.nabble.com/Disabling-serializ
hen the request is completed?
>
> Or is it the responsibility of the application to free old Page instances
> from session state when navigating to different Pages? (It doesn't seem
> like
> this is the case, but I wanted to ask the question anyway.)
>
>- Lu
> --
&
he session)?
Thanks,
- Lu
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13782634
Sent from the Wicket - User mailing list archive at Nabble.com.
-
the responsibility of the application to free old Page instances
from session state when navigating to different Pages? (It doesn't seem like
this is the case, but I wanted to ask the question anyway.)
- Lu
--
View this message in context:
http://www.nabble.com/Disabling-serializati
> What is the recommended deployment model to support back-button usage via
> undoable changes and disk-based serialized storage with Wicket? Is it only
> possible using a load balancer configured to be "sticky" (keep sessions on
> the same node during the lifetime of the session)?
Recommended is
t;>> using
> >>> > sb> spring) but is a heavy(difficult) thing to maintain that "cache"
> >>> per
> >>> > user -
> >>> > sb> http session is a nice and easy storage for that-.
> >>> >
> >>> >
&g
gt;>> per
>>> > user -
>>> > sb> http session is a nice and easy storage for that-.
>>> >
>>> >
>>> > sb> Eelco Hillenius wrote:
>>> >>>
>>> >>>> You should use a second level cache to cache objects and queries
>>> from
>>> >>>> your database;
u'll avoid redundancy in caching, and have caching
> >> >>> regardless of whatever UI framework you're using. and using e.g.
> >> >>> ehcache can do things for you like limit the RAM cache and overflow
> >> to
> >> >>> disk. Etc.
gt; >>>> your database; and that's not Wicket's job, Wicket is a Web
>> framework.
>> >>>>
>> >>>> For example, use Hibernate + ehcache.
>> >>>
>> >>> Yep. That way you'll avoid redundancy in
work.
> >>>>
> >>>> For example, use Hibernate + ehcache.
> >>>
> >>> Yep. That way you'll avoid redundancy in caching, and have caching
> >>> regardless of whatever UI framework you're using. and using e.g.
> >>> ehcache can do things fo
g. and using e.g.
>>> ehcache can do things for you like limit the RAM cache and overflow to
>>> disk. Etc.
>>>
>>> Eelco
>
>
> --
> /Gwyn
>
>
> -
> To
serban.balamaci wrote:
I am just saying that it may be ok in some cases to keep state on
some objects and not have detachable models.
I agree.
Anything that uses a List of database entities, I tend to put in a
detachable model.
If I'm merely using a single POJO that was originally pulled fr
e
>> >> >> entire model-data/components would probably bring in too much of a
>> >> load
>> >> >> on
>> >> >> the system (in my opinion...given high volume of users..) so with
>> that
>> >> >> may
>> >&
Hi,
It's not hard to do it with Wicket, but I'm fairly sure that
for the typical web-app, the metrics showed that the a re-request to
database wasn't a big issue, whereas the gain in terms of reducing the
session size was, especially where it needs replicating.
As such, the recommendation is as i
>> be we would not want to store the pages in pageMap at all (which in
> >> turn
> >> >> is
> >> >> stored in the session).
> >> >
> >> > But I hope you're not storing MBs of data in your pages?! Users will
> >> > a
---
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-
> You should use a second level cache to cache objects and queries from
> your database; and that's not Wicket's job, Wicket is a Web framework.
>
> For example, use Hibernate + ehcache.
Yep. That way you'll avoid redundancy in caching, and have caching
regardless of whatever UI framework you're u
ED]
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13653854
Sent from the Wicket - User mailing list archive at
Nabble.com<http://nabble.com/>
.
---
that are MBs large? Note that you don't have to
>> > keep anything in memory if you work with detachable models.
>> >
>> > Eelco
>> >
>> > -
>> > To unsubscribe, e-mail: [EMAIL
> -----------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Disabling-s
> Well that was just hypothetically speaking..what i meant was it would have
> loads of data loaded in it..so it was that scenario where i was wondering
> that we shouldnt store the state of each page.
> Yes as you pointed out using detachable models can certainly be one to way
> to go..but at the
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Disabling-serialization-stor
> Now there would be certain use-cases/pages in our application which would
> have alot of data in it (lets say in mbs), and in that scenario storing the
> entire model-data/components would probably bring in too much of a load on
> the system (in my opinion...given high volume of users..) so with
>
>> Guys,
>>
>> If need be, can we disable altogether the storage of pages (in the form
>> of
>> a
>> pageMap) in session, similarly on the disk ?
>>
>> Thanks and Regards,
>>
>> Farhan.
>> --
>> View this message
PROTECTED]> wrote:
>
> Guys,
>
> If need be, can we disable altogether the storage of pages (in the form of
> a
> pageMap) in session, similarly on the disk ?
>
> Thanks and Regards,
>
> Farhan.
> --
> View this message in context:
> http://www.nabble.com/Disabli
> If need be, can we disable altogether the storage of pages (in the form of a
> pageMap) in session, similarly on the disk ?
Yep. One easy way to achieve this is to provide a dummy page store.
Eelco
-
To unsubscribe, e-mail: [E
Guys,
If need be, can we disable altogether the storage of pages (in the form of a
pageMap) in session, similarly on the disk ?
Thanks and Regards,
Farhan.
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13638150
52 matches
Mail list logo
