-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andy,
Andy Moller wrote:
>> 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?
>
>
> [Chris]: It is a mistake while changing the variable naming, the variable name
> should be "val2" not "value2", i have to alter the namings
Okay, no problem. I just wanted to make sure that your problem wasn't
some mixed-up variable names. You did say "the jsp page contains these
exact lines of code".
>> 2. You really should be using PreparedStatements instead of string
>> concatenation for parameter replacement.
>
> [Chris]: 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.
Well, if you had been using a PreparedStatement, you would never have
been able to assign a string to a numeric parameter, since you would
have been using PreparedStatement.setInt(int index, int value).
You would have probably been been getting a ClassCastException
(String->Integer) instead of an unexpected query.
>> 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.
>
> [Chris]: the value of the "commonName" is set ONLY ONCE at the session
> initialization, 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.
Okay. Can you print out the commonName attribute in that filter along
with the session id? Your code looks pretty straightforward for building
that query... I'm having a hard time believing that the commonName local
comes from the session and gets changed somewhere in there.
>> So... what's going on here? During the processing of this request, can
>> you ever see session.getAttribute("commonName") returning the correct
>> value?
You didn't answer this part: can you show that the session contains the
correct value and that it somehow changes between your fetch from the
session and your use of the value in your SQL query?
>> 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.
>
>
> [Chris]: 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.
Okay, and it shows that the session you should have has the proper
commonName value? What about after this SQL query thing happens? Does
the commonName in the session return to its previous value, or does it
remain forever changed?
> [Chris]: 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.
There are only two places that I think Tomcat could possibly be
interfering with your code:
1. TC could be giving you the wrong session randomly and inconsistently.
The chances of this being your problem are extremely low. If TC did
not handle sessions properly, there would be a lot more people
complaining about session loss and confusion. You are not the only
one still using TC 4.x (I still use TC 4.1 in production
applications, and it's working just find for me).
2. TC could be shadowing your commonName variable in your JSP without
you knowing about it. For instance, you can use the "session" local
within your JSP without actually defining it because the JSP
container provider it for you. Something similar might be happening
with commonName. This seems like a long shot, especially since
you are explicitly declaring and defining your variable in the JSP,
which would cause a compiler error during JSP translation and
compilation.
I'm not just trying to say that you're wrong about TC being the culprit:
TC has occasionally had bugs. But the version you are using is mature
enough that most of the things that anyone is ever going to find have
already been fixed, so the chances of you binding a bug (especially one
of this magnitude) are super low.
I'd like to try to help you solve this issue, but you seem so confident
that the problem is not in your code that you are unwilling to investigate.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFth9y9CaO5/Lv0PARAlM0AKCmNpR9y5/Yx5i5ffx1KFzNEYzcnwCePNSD
sZAlNAe80Qc7gY7myNIk0wQ=
=w2V9
-----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]
