[
https://issues.jboss.org/browse/ELY-957?page=com.atlassian.jira.plugin.sy...
]
Martin Choma commented on ELY-957:
----------------------------------
On read there have to be ensured correct/fresh data is picked up by:
- synchronized keyword
- volatile keyword
Current implementation DefaultSingleSignOnEntry choose volatile approach. It is correct.
My concern is that all future implementation of SingleSignOnEntry must think on that and
use volatile approach to be correct.
On the other hand if DefaultSingleSignOn.getIdentity use synchronized keyword, all future
implementation will be safe.
Does it make sense to you?
From my PoV moving synchronized modifier to synchronized block,
doesn't change situation.
Coverity static analysis: DefaultSingleSignOn.getIdentity() not
synchronized
----------------------------------------------------------------------------
Key: ELY-957
URL:
https://issues.jboss.org/browse/ELY-957
Project: WildFly Elytron
Issue Type: Bug
Components: HTTP
Affects Versions: 1.1.0.Beta24
Reporter: Martin Choma
Assignee: Paul Ferraro
Priority: Minor
Coverity static-analysis scan found getter is not synchronized, while setter is.
{code}
public SecurityIdentity getIdentity() {
return this.entry.getCachedIdentity().getSecurityIdentity();
}
{code}
Current implementation is correct because in DefaultSingleSignOnEntry (currently only
avalaible implementation of SingleSignOnEntry) cachedIdentity is volatile.
However other implementations can be wrongly implemented. Once getIdentity() would be
marked with synchronize modifier, such problem shouldn't occure.
https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=84908...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)