| Summary: | [server] Thread safety of workspace metadata back end | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | John Arthorne <john.arthorne> |
| Component: | Server | Assignee: | 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
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. |