Community
Participate
Working Groups
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.
Has this been addressed at all?
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.
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.
