Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 339602

Summary: [server] Thread safety of workspace metadata back end
Product: [ECD] Orion Reporter: John Arthorne <john.arthorne>
Component: ServerAssignee: Anthony Hunter <ahunter.eclipse>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: P2 CC: ahunter.eclipse, bokowski, ken_walker, mamacdon, pwebster, Szymon.Brandys, tomasz.zarna
Version: 0.2   
Target Milestone: 7.0   
Hardware: PC   
OS: Windows 7   
Whiteboard:
Bug Depends on: 406607    
Bug Blocks: 440005    

Description John Arthorne CLA 2011-03-10 16:47:38 EST
Workspace metadata is stored in three preference nodes: Workspace, Project, User. These objects are individually thread safe and self-consistent. However, the WorkspaceServlet methods sometimes access and combine data from multiple of these objects during any given request. The result is that concurrent WorkspaceServlet requests can see partial or inconsistent view of the metadata. Access to these back-end structures needs to be synchronized, preferably in a fine-grained manner, e.g., use a ReadWriteLock to allow concurrent reads if there are no writes occurring.
Comment 1 Boris Bokowski CLA 2011-06-07 16:05:37 EDT
Has this been addressed at all?
Comment 2 John Arthorne CLA 2011-06-07 16:12:40 EDT
It was fixed at the front end by synchronizing WorkspaceServlet. Synchronizing closer to the back end would allow more concurrency, which is important in the long term for scalability. I deferred this because I'm not confident that our current metadata storage is the best long term answer. If we wanted a really robust/scalable server we should probably replace our hand-written back end with a third party blob store or database that had built in locking support.
Comment 3 John Arthorne CLA 2015-01-08 11:43:41 EST
This was done in Orion 7.0. There is now both in-memory locking to protect against concurrent thread access, and file level metadata locking to support multiple concurrent Orion server instances.