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
Hi Timo,
Thanks for the suggestion -- I definitely agree that using the source code
and reading it thoroughly will help us understand the inner workings of
Wicket. However, I would call that a white box approach. :)
My hope was to see if I might find some explanations and answers from the
round-robin has a couple of disadvantages over sticky sessons:
a) you need to replicate state to all nodes - a lot of traffic
although with a fiber backplane its most likely not an issue. with
sticky sessions you only have to replicate to one or two other nodes
which act as backup buddies.
b)
you will get an error, i have explained this in a parallel thread
yesterday... that is why we are working on a special page store that
will also write out the current page onto the disk when the session is
replicated - that means all nodes will have all the pages spooled to
disk so clustering will
Fair enough. Good answer. :)
Of course I meant in the non-failure case.
So under normal operations outside of failure conditions, perhaps there
really is no benefit to move users to other nodes during the lifetime of a
session, or at least the difficulty outweighs the benefit.
- Lu
On Nov 16, 2007 8:37 AM, saenz [EMAIL PROTECTED] wrote:
Johan, are you saying that other types of load balancing strategies besides
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
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:
By the way, my question below still has not been answered. Can anyone explain
what would occur in the following scenario?
My question regarding on-disk page storage relates to the use case of a
web-app deployed on a cluster. In this situation, what will happen if the
following occurs?
1.
what do you mean with disabled? how is it disabled?
The page can't be serialized because of none serializeable attributes?
Then in the default 1.3 configuration that page can't be saved to disk so
you can't restore it.
johan
On Nov 16, 2007 8:56 PM, saenz [EMAIL PROTECTED] wrote:
Also, can
Application
*
protected* *abstract* ISessionStore newSessionStore();
johan
On Nov 16, 2007 8:54 PM, saenz [EMAIL PROTECTED] wrote:
igor.vaynberg wrote:
you can still cluster 1.3.1 easily. either use httpsessionstore or
tell wicket to save pages to a shared drive
Thanks Igor.
How can he be more specific than give you the method you need to override?
Martijn
On Nov 17, 2007 12:53 AM, saenz [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.
Johan
Johan Compagner wrote:
what do you mean with disabled? how is it disabled?
The page can't be serialized because of none serializeable attributes?
Then in the default 1.3 configuration that page can't be saved to disk so
you can't restore it.
Hi Johan,
What I mean is by using the
Hi Martijn,
I think so.
You could let us know if we should subclass Application directly or subclass
WebApplication. I would assume the latter.
You could also explain some of the details of what should be returned by our
override of WebApplication.newSessionStore(). The javadoc for this method
you know, the code is all there. you could just look at it...
-igor
On Nov 16, 2007 5:04 PM, saenz [EMAIL PROTECTED] wrote:
Hi Martijn,
I think so.
You could let us know if we should subclass Application directly or subclass
WebApplication. I would assume the latter.
You could also
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
Johan Compagner wrote:
The DiskStore is for the backbutton and the PageMap (thats in the session)
is for the current page. And as long as that page is statefull you have to
store it in the session.
What is the lifetime of a Page object stored in the session?
Does Wicket manage the
Eelco Hillenius wrote:
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.
My question regarding on-disk page storage relates to the use case of a
I think your example should be simplified to include only Page A. Imagine the
Facebook profile page:
- You can add a wall post and after that you land on the same page with the
new post shown on top.
- This (in Wicket's way) should create 2 versions of your FB profile page.
One with the posted
its pretty accurate yes but a back link on V2 to V1 is a pretty special made
thing
Because there is normally not really a link to a previous page. Because on
the javaside
you don't know that really. But you can ask for a specific page version if
you want.
johan
On Nov 13, 2007 3:07 PM, Aqeel
Why is everybody pointing out not to have database data inside the page? Many
times retrieving the data from the database could be the slowest thing and
having that sort of cache is one nice thing in my opinion. Is it not much
better to have data in the session? I understand that it will be a
Hi,
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.
Regards,
Sebastiaan
serban.balamaci wrote:
Why is everybody pointing out not to have database data inside
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
Most database expensive operations come from the result of stored
procedures(my current experience at least). A cache solution can be
implemented by caching the method results with spring(in case of using
spring) but is a heavy(difficult) thing to maintain that cache per user -
http session is a
Also caching data inside a session and having those object over multiply
request
gives in hibernate always errors like LazyInitalizationException or
Transient/StaleObjectException
Holding on to data in sessions is really a bad idea because you dont know
when they come back
if you have a session
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'm not for not considerate caching outside the web layer or a naive aproach
to cache everything even if that object changes 10 times a sec. I am just
saying that it may be ok in some cases to keep state on some objects and not
have detachable models. I'm not saying keep all in session and pay no
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
I agree..and i would say its mostly the nature of the applications which
would help determining whether storing the data in the wicket session would
be a good idea or not...
Further i believe that 99% of the times one just comes to the need of
accessing the last page-instances (lets say through
if you press the back button only once then the page needs to come from
disk.
So if your users never use the back button then yes you only need to have
the last accessed page in the pagemap.
johan
On Nov 9, 2007 10:36 PM, mfs [EMAIL PROTECTED] wrote:
I agree..and i would say its mostly the
its not the lasst access page of a Page.
Its the last access page of a page in a pagemap what ever it is PageA or
PageB or PageZ
On Nov 10, 2007 12:31 AM, mfs [EMAIL PROTECTED] wrote:
In what context are you refering to the back button here...Lets say we
have
two page instances of type
like eelco said if you don't want to serialize and store on disk, create a
filestore that does nothing
(or holds a few pages for per session in mem for backbutton)
But what do you mean with disable the storage of pages in a session?
You don't want to store a statefull page at all in the pagemap
Basically we are still researching wicket and figuring out if that would be
the desired framework for us (so far it does look promising)..and in that
context we are exploring all the different
scenarios/use-cases/possibilities...
Now there would be certain use-cases/pages in our application
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
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 same
36 matches
Mail list logo
