On Feb 6, 2008 4:40 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> 1. I've always experienced some sudden "session expiration"
> problems with no apparent reason (I mean, the user wasn't
> actually sleeping). But they happened only once in a while.
> After upgrading to 1.3 they occur very often and they have
> quickly become the issue on the top of the list and I've to
> fix it immediately, since it's jeopardizing the acceptance
> tests performed by my customer. I've already searched in
> forums and tried some change (such as disabling versioning),
> but I got no benefit from it.
My guess is that #3 is causing it...see my answer there.
> 2. I have a modal window used to enter a date (I can't use
> the already provided component since this a special date)
> that has been working from several months. After upgrading
> to 1.3 it deterministically causes a session expired
> whenever it's closed (since this is deterministic I bet it's
> a different thing than the above).
Are you using our modal window implementation or your own?
> 3. I have still some confusion about serialization of things
> in sessions. I've always got some objects that are not
> serializable and caused tons of exceptions in log files, but
> no harm other than it. I'm now wondering whether they can
> trigger one of the above problems, and anyway before going
> into production I'd like to face with this issue in a
> definitive fashion. I know about the possibility of using
> detachable objects, nevertheless I need first to understand
> why this serialization thing can't be disabled - after all
> I've got no need for clustering in near future (and if I
> should do it, I'd probably go with Terracotta). Also, in
> version 1.2 I once saw that there was a UserSession (?)
> method that looked like it was useful for disabling
> serialization, and I had a mental note about using it, but
> it looks like it disappeared in 1.3.0. Hints?
Serialization has always been needed in wicket for things other then
cluster replication. Versioning has been one of those reasons. We
would use serialization mostly for cloning an object, so that we can
keep a reference to its previous state for rolling back a version.
With 1.3.1 this has changed dramatically. In order to free up session
space (1.2 would keep x pages in session) 1.3.1 only keeps the most
current page in session and spools older pages to disk via
serialization. So if you hit a page that has a serialization problem
and later come back to it via back button and click a link/submit a
form you will get a page expired error. My recommendation is to make
sure you use detachable models or make your objects serializable. In
the meantime, try
class MyApplication extends WebApplication { ISessionStore
newSessionStore() { return new HttpSessionStore();}}
that will turn off disk spooling and will make 1.3 behave more like
1.2 in that regard.
-igor
>
> Thanks in advance..
>
> --
> Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici -
> www.tidalwave.it/blog
> [EMAIL PROTECTED] - mobile: +39 348.150.6941
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
