Re: Disabling serialization/storage of pages in session?

[Sebastiaan van Erk]

Hi,




For example, use Hibernate + ehcache.

Regards,
Sebastiaan

serban.balamaci wrote:

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.

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 negative
point in clustering for session replication, but that might not be such a
drawback. The state could be replicated to the other server asyncroniously
after the request was presented back to the user so he sees no degradation
in performance, or better use sticky load balance and not have session
replication. Also you might need to sacrifice the availability of the back
button, although by keeping multiple versions of the page that can be
avoided? Are there other negatives?.


Johan Compagner wrote:

Use detachable models.. Never keep database data live inside your models
just store the minimal state so that you can construct it again.

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
There is no other way because that wouldn't make any sense.

johan

On Nov 8, 2007 8:22 PM, mfs <[EMAIL PROTECTED]> wrote:

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 time since i am sort of presenting my company with
all the features, i want to be prepared with answers and would want to
know
as much as i can..

So with what i understand the page serialization can be disabled by
providing a dummy page-store but the storage of pages in the pageMap and
hence in the current active session is something which is implicit and
not
something we can avoid..



Eelco Hillenius wrote:

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 that
may
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
also get pages served 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 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 at
Nabble.com<http://nabble.com/>
.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

smime.p7s
Description: S/MIME Cryptographic Signature