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
/
-
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-in-session--tf4768006.html#a13816999
Sent from the Wicket - User mailing
-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13796995
Sent from the Wicket - User mailing list archive at Nabble.com
?
--
View this message in context:
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
.
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?
- Lu
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session
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-storage-of-pages-in-session--tf4768006.html#a13796491
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
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-pages-in-session--tf4768006.html
page1 once more
4. Now the silly user presses the back button, over and over.
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-serialization-storage-of-pages
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-pages-in-session--tf4768006.html#a13800441
. 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/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13800373
Sent from
Compagner wrote:
Application
*protected* *abstract* ISessionStore newSessionStore();
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13804076
Sent from the Wicket - User mailing list archive at Nabble.com
?
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.
-
To unsubscribe, e-mail
to the documentation 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.html#a13804076
Sent from the Wicket - User mailing
();
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13804076
Sent from the Wicket - User mailing list archive at Nabble.com
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 your
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 to
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-serialization-storage-of-pages-in-session--tf4768006
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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED
PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13675586
Sent from the Wicket - User mailing list archive at
Nabble.comhttp://nabble.com
, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13726523
Sent from the Wicket - User mailing list archive at
Nabble.comhttp://nabble.com
-
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-in-session--tf4768006.html#a13653854
Sent from the Wicket - User mailing list archive
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.comhttp://nabble.com/
.
-
To unsubscribe, e-mail: [EMAIL PROTECTED
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
]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13663495
Sent from the Wicket - User mailing list archive at Nabble.com
-
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-in-session--tf4768006.html#a13653854
Sent from the Wicket - User
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
]
--
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/http://nabble.com
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
]
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13675586
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail
]
--
View this message in context:
http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13675586
Sent from the Wicket - User mailing list archive at
Nabble.comhttp://nabble.com
-
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-in-session--tf4768006.html#a13675586
Sent from the Wicket - User mailing
,
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
, 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
Sent from the Wicket - User mailing list archive at
Nabble.comhttp://nabble.com
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
PROTECTED]
--
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.
-
To unsubscribe, 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
37 matches
Mail list logo
