-
Bug
-
Resolution: Tracked Elsewhere
-
High
-
None
-
2.6.0, 5.3-OD-11, 5.5-OD-28
-
None
-
33
-
NOTE: This bug report is for Confluence Server. Using Confluence Cloud? See the corresponding bug report.
The following errors can occur in the logs after two threads attempt to access and then successfully create a single User's User Info (aka userinfo, PersonalInformation, personal information)
2007-10-28 02:15:29,871 ERROR [TP-Processor3] [com.atlassian.hibernate.HibernateObjectDao] findSingleObject Uh oh - found more than one object when single object requested: [userinfo: testuser1 v.1 (15763661), userinfo: testuser1 v.1 (15763669)]
The HibernatePersonalInformationDao has a getByUsername method that calls the findSingleObject method which selects the single PersonalInformation object
from Content info
where info.originalVersion is null and
info.username = ?
Unfortunately, there is little enforcement that there is only one PersonalInformation for each user with a null version. There is only high level code that checks the Object can't be fetched from the database before creating the object and sending it to the persistence layer. It's not even synchronized, so this bug isn't confined to clustered instances.
It's occurrence is still quite improbable. It does require two separate threads to require the user's PersonalInformation at approximately the same time, but it can and does happen and it should be stopped. The obvious solution is to add a uniquenesss constraint to the PersonalInformation subclass definition in ContentEntityObject.hbm.xml on the (Username, Version) attribute pair. Note that the username is only used for PersonalInformation objects.
- is blocked by
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- is incorporated by
-
-
- Closed
-
- is related to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
CONFSERVER-33543 Filter out duplicates in people directory
- Closed
- relates to
-
-
- Closed
-
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[CONFSERVER-9857] PersonalInformation (userinfo) fetching assumes a uniqueness constraint that isn't enforced
Still an issue, we even managed to create a situation where users where shown three times
jmasson@atlassian.com Its pretty much as bumped as it can be short of making it a blocker (which seems silly as the issue has existed since 2007).
There was an attempt to fix this issue, however the problem proved to be much more difficult than originally thought. Here is some background info:
As originally mentioned the duplicate Personal Information objects created when two threads simultaneously attempt to access and then successfully create PersonalInformation object, each unaware that the other thread is also creating one. To fix the problem we need to prevent such situation from happening. Thread synchronization techniques do not work in this situation because each of the thread creates PersonalInformation object within its own database transaction and it only becomes visible when the transaction is committed. We have considered using a combination of inner transactions and granular synchronization, however this approach does not work for some transaction isolation levels (eg. Repeatable Reads), also database support for inner transaction is patchy.
We also investigated the possibility of creating a uniqueness constrain on the table that would prevent duplicate PersonalInformation rows. However in our current db schema the constrain would have to be put on columns that can be null, and different databases treat such constrain differently (some databases consider two rows with null values duplicates).
The only feasible way to actually fix the problem is to revise the db schema for personal information object (i.e. store them in a different table) and put the uniqueness constrain on the new table.
Per Fragemann [Atlassian]
added a comment - I am clearing the fix-for-version since the problem is not solved yet, and won't be in 3.1
Per Fragemann [Atlassian]
added a comment - I am clearing the fix-for-version since the problem is not solved yet, and won't be in 3.1 
James Roper [Atlassian]
added a comment - It does affect Confluence's functionality, each duplicate appears twice in the people directory, causing confusion for users.
By the way, I am able to reproduce this on occasion, but not on demand. I believe it's a race condition, which is why there are no concrete steps to reproducing it, sometimes it happens, sometimes it doesn't.
James Roper [Atlassian]
added a comment - It does affect Confluence's functionality, each duplicate appears twice in the people directory, causing confusion for users.
By the way, I am able to reproduce this on occasion, but not on demand. I believe it's a race condition, which is why there are no concrete steps to reproducing it, sometimes it happens, sometimes it doesn't. Hi all,
The underlying problem does not affect confluence's functionality as the same PersonalInformation object will always be returned for a particular user even if there are more than one fetched from the db (we always return the one with the lowers id). I have made changes so that the error message is no longer logged (unless in a debug mode). However I will not close the issue as we still don't enforce the uniqueness of personal information objects.
All versions of confluence starting from 3.0.2 will have those changes.
Anatoli.
Vishal J
added a comment - Is their any update on this issue, we are facing the same one using confluence 2.7.3
Our confluence also get slow because of this error.. so many logs in log file.
Regards
Vishal J
added a comment - Is their any update on this issue, we are facing the same one using confluence 2.7.3
Our confluence also get slow because of this error.. so many logs in log file.
Regards 
Deleted Account (Inactive)
added a comment - We see this on confluence 2.10.3
Tracking this on
CONF-30050, which more accurately describes the customer facing problem