On 1/22/07, Christopher Schultz <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andy,
Andy Moller wrote:
> String commonName = (String)session.getAttribute("commonName");
> String[] value1 = (request.getParameterValues("value_1") != null)
> ? request.getParameterValues("value_1")
> : new String[0];
>
> String[] value2 =
> (request.getParameterValues("value_2") != null)
> ? request.getParameterValues("value_2")
> : new String[0];
[snip]
> query=
> "insert into sample_table(id,val1,common_name,val2)"
> + " values (sequence.nextVal,"
> + singleVal1
> + ",'"
> + commonName
> + "','"
> + val2[j]
> + "')";
A few notes:
1. You are using the array "val2" here instead of "value2". Is that
intentional? Or, were you somewhat obfuscating your code for publication
on the list?
Andy: It is a mistake while changing the variable naming, the variable name
should be "val2" not "value2", i have to alter the namings
2. You really should be using PreparedStatements instead of string
concatenation for parameter replacement.
Andy: you are right, but this is one "way" to do it, It has performance and
other issues but it should not affect the final results.
3. These is no evidence that "commonName" ever had the value that you
expected. Your initial claim was that the value was being taken from the
session and, between that time and the issue of the SQL query, the value
was being changed.
Andy: the value of the "commonName" is set ONLY ONCE at the session
initalization, and not updated during the session life, you can think about
it as an application specific session ID. A filter ensures the existance of
a valid "commonName" with each request, otherwise the access to the JSP page
is not permitted
So... what's going on here? During the processing of this request, can
you ever see session.getAttribute("commonName") returning the correct
value? Or, has the session really been polluted somehow, or have you
really "swtiched" sessions somehow?
Andy: (same note as above)
Where the value "nameB" is the "commonName" session attribute value from
> a different session.
Is there any relationship whatsoever between the session you should have
and the session that you are apparently getting? Are you /sure/ that
there is another session containing that value, or are you assuming that
since it's not the expected value that you must be looking at another
session.
Andy: I am sure there is another session with the "nameB" at the same time i
had that incident, the application has a filter that keep track of the
session requests and activities, it keeps a log with requests and operations
for every session from start to end.
Is your entire application written in JSP? I'm wondering if you ever try
to manage sessions yourself in any way.
Try this: create an HttpSesssionBindingListener and implement the
valueBound method like this:
public void valueBound(HttpSessionBindingEvent esbe)
{
if("commonName".equals(esbe.getName()))
{
System.out.println("Setting session["
+ esbe.getSession().getId()
+ "].commonName="
+ esbe.getValue());
new Throwable().printStackTrace(System.out);
}
}
This will put a full stack trace into stdout whenever the value of
commonName for a session is changed. I'm assuming that you have a test
plan that is reproducing this error in development, so you can watch the
logs as you move through your application.
Login and watch the logs. You can see when a value is poked into the
session, and what that value is. If you see that the value is changing
in your session (and it shouldn't be), then you'll see the stack trace
of the code that's doing it.
You can install this listener using a <listener> element in your web.xml
like this:
<listener>
<listener-class>your.package.ComonNameSessionBindingListener
</listener-class>
</listener>
This goes after any <filter> and <filter-mapping> elements and before
any <servlet> elements.
Andy: I have not attempted a similar check, though the filter I mentioned
earlier logs the session variables with each request. I was not suspecting
session variables until I stumbled upon that statement in the error log. We
tried to simulate random sessions and perform similar operations per each
session to overload the JDBC drivers but all operations went ok.
That issue occurs on relatively far intervals and in a random fashion; we
are trying to systematically isolate each component and so far we have just
started debugging Tomcat as a possible cause.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFtTXT9CaO5/Lv0PARAjY2AJ92nhsTHaW9IQTIETpM1J40gAcwSQCeMyWr
sp4svE3vaNqmhp6iCFqLWqI=
=HlHR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I hope this adds useful information to the discussion,
Thank you,
Andy
