That's very odd... As I understood, methods on the Session can be called by
several threads. So, Session methods must be thread safe.
Maybe something is wrong with your dao. (Since that wone will be called by
multiple threads a the same time...)
Pieter
On Fri, Jan 8, 2010 at 12:17 PM, Soumya
If your servlet container bind an different session for your users requests,
you get the problem described too. Only one property of your session has
user B values for user A requests? Or the entire session are different?
On Fri, Jan 8, 2010 at 9:52 AM, Pieter Degraeuwe
Look for static variables on your code too, they may be erroneous sharing
values between session.
On Fri, Jan 8, 2010 at 10:00 AM, Pedro Santos pedros...@gmail.com wrote:
If your servlet container bind an different session for your users
requests, you get the problem described too. Only one
A wicket version number would be helpful...
Martijn
On Fri, Jan 8, 2010 at 12:17 PM, Soumya soumya_...@yahoo.co.in wrote:
Hi all,
I am fairly a newbie in wicket and would appreciate your help!
I
have a wicket application which are used on Live by more than 500
users. Now the problem which
Hi,
The wicket version is 1.3. Sorry should have mentioned that.
As such the User A, after he logs on is getting assigned the Account object
of User B. And after soem logs we can see that User B had logged on a while
before. Hence that Accoutn object was definitely fetched a whiel before. I
did
1.3.0?
Martijn
On Fri, Jan 8, 2010 at 1:12 PM, allgo soumya_...@yahoo.co.in wrote:
Hi,
The wicket version is 1.3. Sorry should have mentioned that.
As such the User A, after he logs on is getting assigned the Account object
of User B. And after soem logs we can see that User B had logged
1.3.0-beta3 actually. Copied it from the Manifest file
Martijn Dashorst wrote:
1.3.0?
Martijn
On Fri, Jan 8, 2010 at 1:12 PM, allgo soumya_...@yahoo.co.in wrote:
Hi,
The wicket version is 1.3. Sorry should have mentioned that.
As such the User A, after he logs on is getting
The first thing to do would be to reproduce the issue in a dev environment,
then try upgrading that environment to 1.3.7 and see if that solves the
problem. There shouldn't be any API breaks in the 1.3 series so this should be
a simple POM dependency version update.
It might also be your
unfortunately it is extremely difficult to reproduce in dev. Have tried it a
lot. but the issue seems to happen vaer rare in a multi-user env. Thing is
though ti happens rarely... it is a client facing issue and data integrity
as promised is challenged.
Steve Swinsburg-3 wrote:
The first
Are there any issues reported in the Wicket JIRA [1] that affect the 1.3 series
in this way? Can you just upgrade Wicket version to 1.3.7 to see if that
resolves your issue? Then you can keep digging.
[1] http://issues.apache.org/jira/browse/WICKET
On 08/01/2010, at 11:40 PM, allgo wrote:
Seriously... *BETA*? upgrade and then come back if things are still wrong.
Martijn
On Fri, Jan 8, 2010 at 1:21 PM, allgo soumya_...@yahoo.co.in wrote:
1.3.0-beta3 actually. Copied it from the Manifest file
Martijn Dashorst wrote:
1.3.0?
Martijn
On Fri, Jan 8, 2010 at 1:12 PM, allgo
The session object is bound to the HttpSession, so it is as safe as Tomcat or
whatever servlet container is running your application.
Here are some things to consider that have bit me in the butt, and have nothing
to do with your local setup:
* Is that happening locally in your test
ok will do.
But just a question to the experts - have you heard of this issue before?
I went through the links below
http://old.nabble.com/Storing-user-entity-in-session--tt22113666.html#a22113666
http://old.nabble.com/Wicket-Session-and-threading-tt14595666.html#a14599963
and apparently
Hi Berin,
No the users are all from different companies and no way there woudl be
caching of their side. User A belongs to a client X say working in New York
, while User B may be of client Y working in texas.
It doesnt happen in test environment. but then that is not a multi-user
environment
There has been a session leak somewhere in 1.3 iirc. This has to do
with the thread locals that store Session, RequestCycle and
Application during a request not being removed correctly.
Martijn
On Fri, Jan 8, 2010 at 2:38 PM, allgo soumya_...@yahoo.co.in wrote:
ok will do.
But just a question
, unfortunately. If your system
lives in a DMZ (which it sounds like it might), then the proxy server
might be within your ISP.
-Original Message-
From: allgo [mailto:soumya_...@yahoo.co.in]
Sent: Friday, January 08, 2010 8:44 AM
To: users@wicket.apache.org
Subject: RE: Wicket session
1.3.4 fixed this issue
From the release notes [1]:
* cross session leakage due to a dangling thread local in exceptional
circumstances
* memory leak in localizer (WICKET-1667)
Martijn
[1] http://wicket.apache.org/news.html#News-ApacheWicket1.3.4released%21
On Fri, Jan 8, 2010 at 2:56 PM,
the fix was a by-product of this issue:
https://issues.apache.org/jira/browse/WICKET-1409
So yes, upgrading to 1.3.4 or newer will fix your issue. Go convince
your management and tell them that it helps to keep up-to-date with
open source products because we tend to fix things (at no cost for
Thanks a Ton Martijn and Berin!
I will soon try an upgrade to 1.3.4 and try it out.
Once again my sincere thanks to you all for your speedy help!
Martijn Dashorst wrote:
the fix was a by-product of this issue:
https://issues.apache.org/jira/browse/WICKET-1409
So yes, upgrading to 1.3.4
On Fri, 2010-01-08 at 15:21 +0100, Martijn Dashorst wrote:
the fix was a by-product of this issue:
https://issues.apache.org/jira/browse/WICKET-1409
So yes, upgrading to 1.3.4 or newer will fix your issue. Go convince
your management and tell them that it helps to keep up-to-date with
Why not upgrade to 1.3.7? AFAIK there shouldn't be any differences in API or
functionality between 1.3.4 and 1.3.7, so you might as well benefit from the
other bugfixes as well. It's only if you should decide to upgrade to the 1.4
releases, that you will have to do some coding. (And even that
21 matches
Mail list logo
