retrieving two different objects from session (should be the same)

[Abid Hussain]

Hi everybody,

I'm using tomcat 5.5.9 and am encountering a strange behaviour. I'm not
sure, if it may be a tomcat issue...

I'm putting an object (called form) into the user's session using
session.setAttribute() and retrieving it again (after the user has done
some actions) using session.getAttribute().

Now look at my log messages:
Before putting the object into session:
Put form (modulverwaltung.forms.ModuleForm@10e1567) in session
(42A90C9AAEE86B81C916F093AAD69452)
After retrieving it from session:
Form (modulverwaltung.forms.ModuleForm@1678aef) has been submitted, got
it from session (42A90C9AAEE86B81C916F093AAD69452)

As you see the results from calling form.toString() are not the same.
I've neither overriden toString() nor hashCode() - the methods from
java.lang.Object are being used. It seems that this behaviour only
occurs in productive system. In my local system it didn't come up.

Anybody got an idea, how this can happen? Does tomcat modify the objects
in session somehow...?

Best regards,

Abid


--

Abid Hussain
Mail: abid.hussain@...
Web: http://www.abid76.de

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[markt-2]

Abid Hussain wrote:
> Anybody got an idea, how this can happen? Does tomcat modify the objects
> in session somehow...?

Do you have any session persistence configured?

Mark


---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Abid Hussain]

Hi,

thanks for help. As far as I know, persisting sessions is only used when
stopping and restarting tomcat, which didn't happen in my case. So, this
shouldn't be the reason...?

If it's important for this issue, I can have a look in the server.xml.
This would take some time, cause I've no rights to access the tomcat
directore in productive system.

Regards,

Abid

Mark Thomas schrieb:

> Abid Hussain wrote:
>> Anybody got an idea, how this can happen? Does tomcat modify the
>> objects in session somehow...?
>
> Do you have any session persistence configured?
>
> Mark
>
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@...
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--

Abid Hussain
Mail: abid.hussain@...
Web: http://www.abid76.de

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Caldarale, Charles R]

> From: Abid Hussain [mailto:abid.hussain@...]
> Subject: Re: retrieving two different objects from session
> (should be thesame)
>
> So, this shouldn't be the reason...?

Are you properly synchronizing accesses to the session for concurrent
requests?  Browsers will almost always generate multiple concurrent
requests for the same session whenever the page being displayed has
anything embedded in it (e.g., style sheets, pictures).

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Christopher Schultz-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

Caldarale, Charles R wrote:
| Are you properly synchronizing accesses to the session for concurrent
| requests?

Silly question.... how do you do this?

The result of HttpServletRequest.getSession gives you a SessionFacade
which is not guaranteed to be the same as the one given to another
thread accessing the same session (right?). You could synchronize using
an object stored /in/ the session, but then you have to worry about that
object being replaced, etc.

AFAICT, there is no reliable way to synchronize access to the session
other than what the container is already required to provide.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgjD0QACgkQ9CaO5/Lv0PBDbwCfVU8ZRJXVbQzUsLOVbVfz5CrW
usMAoLl5GH9TP3Qs1u/a9cNfOC4OJi7o
=1EnL
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Abid Hussain]

Hi again,

I'm not sure if I got the point. I would have thought that it doesn't
matter if concurrent requests come in, cause:
1. There's only one request which ends up in the servlet where the
described behaviour came up. The other requests which are generated by
the browser wouldn't be delegated to the servlet, cause they are only
requesting static resources (like pictures, etc.).
2. The webapp is normally used by a few users at the same time.
3. Whatever the number of requests is, the session stays the same,
shouldn't it?

Regards,

Abid

Caldarale, Charles R schrieb:

>> From: Abid Hussain [mailto:abid.hussain@...]
>> Subject: Re: retrieving two different objects from session
>> (should be thesame)
>>
>> So, this shouldn't be the reason...?
>
> Are you properly synchronizing accesses to the session for concurrent
> requests?  Browsers will almost always generate multiple concurrent
> requests for the same session whenever the page being displayed has
> anything embedded in it (e.g., style sheets, pictures).
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail
> and its attachments from all computers.
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@...
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--

Abid Hussain
Mail: abid.hussain@...
Web: http://www.abid76.de

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Abid Hussain]

Hi,

> The result of HttpServletRequest.getSession gives you a SessionFacade
> which is not guaranteed to be the same as the one given to another
> thread accessing the same session (right?). You could synchronize using
> an object stored /in/ the session, but then you have to worry about that
> object being replaced, etc.
so this means, it's specified behaviour that there is no guarantee,
having an object placed in session would be the same after retrieving it
after some time...?

Regards,

Abid

--

Abid Hussain
Mail: abid.hussain@...
Web: http://www.abid76.de

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:chris@...]
> Subject: Re: retrieving two different objects from session
> (should be thesame)
>
> Silly question.... how do you do this?

Synchronizing on the SessionFacade will suffice for this purpose -
checking if an attribute exists and then storing it if not.  The
container insures that accesses to the underlying attribute set itself
is synchronized (we had a long and somewhat heated discussion about the
necessity of that a couple of years ago).

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Caldarale, Charles R]

> From: Abid Hussain [mailto:abid.hussain@...]
> Subject: Re: retrieving two different objects from session
> (should be thesame)
>
> 1. There's only one request which ends up in the servlet where the
> described behaviour came up.

Only true if the user never opens two windows/frames targeting the same
servlet - and you have no control over that.  The sporadic nature of the
failure would indicate you have some form of concurrency problem.

> 2. The webapp is normally used by a few users at the same time.

The number of users doesn't matter, since each has a separate session.

> 3. Whatever the number of requests is, the session stays the same,
> shouldn't it?

Yes, which creates the need for synchronization due to the possibility
of multiple concurrent requests for the same session.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Caldarale, Charles R]

> From: Abid Hussain [mailto:abid.hussain@...]
> Subject: Re: retrieving two different objects from session
> (should be thesame)
>
> so this means, it's specified behaviour that there is no guarantee,
> having an object placed in session would be the same after
> retrieving it after some time...?

No, the object will be the same, unless the session is persisted and
reloaded (what Mark T was asking about earlier), or clustering is being
used.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Christopher Schultz-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

Caldarale, Charles R wrote:
|> From: Christopher Schultz [mailto:chris@...]
|> Subject: Re: retrieving two different objects from session
|> (should be thesame)
|>
|> Silly question.... how do you do this?
|
| Synchronizing on the SessionFacade will suffice for this purpose -
| checking if an attribute exists and then storing it if not.  The
| container insures that accesses to the underlying attribute set itself
| is synchronized (we had a long and somewhat heated discussion about the
| necessity of that a couple of years ago).

Okay, cool. I just assumed that

HttpSession session = request.getSession();
Object myObject;
synchroinzed(session) {
~ myObject = session.getAttribute("myObject");

~ if(null == myObject)
~ {
~   myObject = // get new object

~   session.setAttribute("myObject", myObject);
~ }
}

could not be considered threadsafe. Fortunately, I have never had to
write code such as this :)

Can you explain how this is done? My tenuous understanding of session
handling in Tomcat is that HttpServletRequest.getSession roughly returns:

new StandardSessionFacade(theRealSessionObject)

...which means that the "real" session is hidden behind the facade
(makes sense), but that the object implementing the session is therefore
unavailable for synchronization purposes. Since synchronized() isn't a
function call, it can't be virtualized and/or intercepted, so wrapping
the session in a facade actually eliminates the possibility for
synchronization.

I must have this wrong. It's tough to sit down with the code and figure
everything out, though. :(

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgjFVMACgkQ9CaO5/Lv0PBhzgCfZrQkFsf4C7LU9ABWo7RxXjQ1
0h0An0C3RKWSEIVSOVdaJqf9qugcJ/31
=RZ9f
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Caldarale, Charles R]

> From: Christopher Schultz [mailto:chris@...]
> Subject: Re: retrieving two different objects from session
> (should be thesame)
>
> My tenuous understanding of session handling in Tomcat
> is that HttpServletRequest.getSession roughly returns:
>
> new StandardSessionFacade(theRealSessionObject)

Don't think so.  I just took a look at the code, and it appears to me
that the facade is only created once per session, not once per
getSession() call.

I did think of another issue with this situation:  if the attribute
under discussion is only relevant for one particular request, it's a
design flaw to store it in the session.  It should be saved in the
request instead, thereby avoiding any concurrency issues.  Since the OP
didn't really give us much information about the lifetime of the
attribute, I just assumed it had session scope.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Christopher Schultz-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chuck,

Caldarale, Charles R wrote:
|> From: Christopher Schultz [mailto:chris@...]
|> Subject: Re: retrieving two different objects from session
|> (should be thesame)
|>
|> My tenuous understanding of session handling in Tomcat
|> is that HttpServletRequest.getSession roughly returns:
|>
|> new StandardSessionFacade(theRealSessionObject)
|
| Don't think so.  I just took a look at the code, and it appears to me
| that the facade is only created once per session, not once per
| getSession() call.

Okay. I was looking around for that before I sent my message, but I
started to get lost in the Request versus Request versus StandardRequest
versus HttpSevrletRequest versus whatever else is in there.

| I did think of another issue with this situation:  if the attribute
| under discussion is only relevant for one particular request, it's a
| design flaw to store it in the session.

Definitely.

| It should be saved in the
| request instead, thereby avoiding any concurrency issues.  Since the OP
| didn't really give us much information about the lifetime of the
| attribute, I just assumed it had session scope.

Yeah. I'm wondering if he's using some type of form processing library
that re-writes the "form" object in the session each time. Struts, for
example, allows you to define forms for processing to have "session"
scope, and it will create the object and stuff it into the session for
you. There's no guarantee that the form object itself will survive
multiple requests, though the form should always be available. It's
possible that a new object would be created and actually replace the
in-session object, though I don't think that's actually how it's
implemented.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgjIYAACgkQ9CaO5/Lv0PCNWQCffAxYIqwob9qA6NfyItOq+Jwm
CNkAoKWbvtxoyJLZF7sD602CHltbq802
=ZA/o
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Christopher Schultz-2]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin,

Martin wrote:
| are you proposing synchronized access to facade object

No, I'm suggesting that it should be easy enough to:

synchronized(session) {

~  // do something that requires exclusive session access

}

~From what Chuck says, it seems like that is possible.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgjIdAACgkQ9CaO5/Lv0PCusgCfXvW3KYYaxn6cz+8mTvTl/hu7
o4gAoLNPrUny9FnqbzAiQmJYQPX6AcE4
=RD/K
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Abid Hussain]

Hi again,

sorry for delay and thanks for help. Chuck has been absolutely right -
it was a concurrency issue. As he said, it's better to store needed
objects in the request than in the session.

The problem is, I need an object being available for several requests,
so I have to store it in the session. Now I have to find a way to store
objects in session avoiding any concurrency issues...

Regards,

Abid

Caldarale, Charles R schrieb:

>> From: Abid Hussain [mailto:abid.hussain@...]
>> Subject: Re: retrieving two different objects from session
>> (should be thesame)
>>
>> so this means, it's specified behaviour that there is no guarantee,
>> having an object placed in session would be the same after
>> retrieving it after some time...?
>
> No, the object will be the same, unless the session is persisted and
> reloaded (what Mark T was asking about earlier), or clustering is being
> used.
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail
> and its attachments from all computers.
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@...
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--

Abid Hussain
Mail: abid.hussain@...
Web: http://www.abid76.de

---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Alexander Diedler]

Hello,
I have a Windows Vista Business PC and my Account is members of the local Administrator Group.
After the Installation and a reboot, I get the Error "Access Denied" when Vista tries to Start the Tomcat6w.exe.
Any idea?
 
Alex
 


---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[markt-2]

Alexander Diedler wrote:
> Hello,
> I have a Windows Vista Business PC and my Account is members of the local Administrator Group.
> After the Installation and a reboot, I get the Error "Access Denied" when Vista tries to Start the Tomcat6w.exe.
> Any idea?

When starting a new thread (ie sending a message to the list about a
new topic) please do not reply to an existing message and change the
subject line. This is known as thread hijacking and to many of the
list archiving services and mail clients used by list subscribers this
makes your new message appear as part of the old thread. This makes it
harder for other users to find relevant information when searching the
lists.

It should also be noted that many list subscribers automatically
ignore any messages that hijack another thread.

The correct procedure is to create a new message with a new subject.
This will start a new thread.

Thanks,

Mark


---------------------------------------------------------------------
To start a new topic, e-mail: users@...
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...