In this situation you have two threads both of which have a reference to the same session -- I suspect the container would give both the same HttpSession implementation object instance but Ive not tested this. Probably container dependant but even so it is conceptually the same session. When one thread invalidates it and the other tries subsequently to use it then logically the potential for such problems is present, though their actual occurance will be intermittent as is the nature of concurrency issues.
Frank W. Zammetti wrote:
Thanks for taking the time to look at it. I've already done what you suggest (I removed all the debug statements in this code by the way). It is only in production, where of course the load is greater (test is barely touched at this point). As I said earlier, fortunately this is pretty rare, happens maybe twice every 75,000 requests, give or take, so it's not a major hassle for anyone. Obviously I want to solve it, but I haven't even gotten any user reports on it, I just see it in my log files (it IS possible that it happens but the users don't see anything... this doesn't seem possible, and other indications tell me they are seeing the usual exception page, so I doubt this is the case).
I did check AccountFB's constructor, but on the chance I'm not seeing something, here it is in it's entirety:
public AccountFB(HttpSession inSession, Connection conn) throws ClassNotFoundException, SQLException, NamingException {
session = inSession;
dbcm = new DBConnectionManager(conn);
}
Both session and dbcm are instance variables... hmmm, as I typed that it dawned on me that maybe I have some subtle threading issue... I never considered that because all the Actions instantiate their own function beans, of which AccountFB is one, and they are always local, so I didn't think there would be any problem... However, I wonder if somewhere in the code base they are being instantiated NOT as locals... If that happened concurrently in two places, maybe the container shares the instance, and hence a difficult-to-track-down little concurrency bug. Doesn't strike me as likely, but I can do a quick scan of the code base tomorrow and see if anything turns up.
I will definitely post a solution if I find one in the next few days. I've been looking at this for probably a month now though off and on, so I'm not too confident.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
