Mark, Thank you for your "kind" response.
> and it seems that there may be a problem there. More specifically, in the > > execute method, getAttribute of Globals.SUBJECT_ATTR is obtained on a > > session > > and then it is set in a non-atomic fashion. > > While that statement is true, you have not explained why this is a > problem in this particular case. > > What more explanation is needed? Two threads having access to the same session object can clobber the attribute. Both threads (A and B) do a getAttribute, find the attribute to be null and create a subject. One of them (A) sets the attribute with a subject with principal x. In the interim, a third thread (C) does a getAttribute, subject is not null and proceeds with using principal x. Now thread B gets scheduled and sets the subject attribute with principal y. Now, aren't the semantics inconsistent between B and C? After C had obtained the subject, the subject is guaranteed to not change. Having looked at this particular code, I see some potential > opportunities for simplifying things but no chance of a threading > problem. If you analysis reaches a different conclusion, please share it. > Why don't you see a threading problem? Is it because multiple threads cannot access this code? Is it because a lost update is not a problem? Is it because the session is not shared? Instead of a blanket "I do not see a threading problem", provide more details so that other new contributors understand and can also help in contributing to the project in the future. Chris.
