Issue Details (XML | Word | Printable)

Key: CONF-8810
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Paul Curren [Atlassian]
Reporter: Anatoli Kazatchkov [Atlassian]
Votes: 0
Watchers: 0
Operations

Add/Edit UI Mockup to this issue
If you were logged in you would be able to see more operations.
Confluence

Deadlock when working with Bandana table, database locks and thread locks

Created: 02/Jul/07 07:25 PM   Updated: 17/Sep/07 03:51 AM
Component/s: Database / Hibernate
Affects Version/s: 2.5, 2.5.1, 2.5.2, 2.5.3, 2.5.4
Fix Version/s: 2.5

Time Tracking:
Not Specified

Environment: MSSQL

Participants: Anatoli Kazatchkov [Atlassian] and Paul Curren [Atlassian]
Since last comment: 1 year, 27 weeks, 2 days ago
Resolution Date: 02/Jul/07 09:22 PM
Labels:


 Description  « Hide
When HibernateConfluenceBandanaRecordDao class is used by 2 threads there is a possibility of deadlock because saveOrUpdate method is synchronized.
Together with database locking it may produce a deadlock.

In this case "Invite" plug-in runs two threads once a day (Remove Unnecessary Invitations Job and Expire Invitations Job). Both use saveOrUpdate synchronized method in a loop.
One of the threads enters saveOrUpdate method and locks the Bandana table in the database - when it exists the method the table is still locked as transaction is not yet committed.
When another thread enters the same method it cannot proceed because database is locked. The initial thread cannot finish its own transaction and commit changes because
it cannot enter the saveOrUpdate method again as the second thread holds the lock on HibernateConfluenceBandanaRecordDao. Hence there is a deadlock.

Synchronization of saveOrUpdate looks redundant as no class instance variables are used in this method. Fix should probably be as simple as removing synchronization.



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Paul Curren [Atlassian] added a comment - 02/Jul/07 09:22 PM
Resolved as suggested in the comments.