tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris R <chris.tech...@gmail.com>
Subject Re: atomicity problem in SecurityUtil.java
Date Sun, 22 Jul 2012 03:54:45 GMT
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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message