This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 120673

Summary: Rewrite repository files cache synchronization
Product: cnd Reporter: Vladimir Kvashin <vkvashin>
Component: Code ModelAssignee: Vladimir Kvashin <vkvashin>
Status: CLOSED FIXED    
Severity: blocker    
Priority: P3    
Version: 6.x   
Hardware: Sun   
OS: All   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 127727    
Bug Blocks: 121530    
Attachments: Stack fragment that illustrates the previous note

Description Vladimir Kvashin 2007-10-31 16:57:14 UTC
This concerns mostly classes o.n.m.c.repository.util.RepositoryCacheMap and
o.n.m.c.repository.disk.SimpleRepositoryHelperCacheImpl that uses the former one. The idea of RepositoryCacheMap is to
provide a cache for open files. This speeds up repository access a lot. But synchronization-related responsibilities
spread between these classes, which is incorrect. This should be rewritten in such a way that RepositoryCacheMap is
responsible for synchronization using an abstract factory pattern. The existing code is error prone.
Comment 1 Vladimir Kvashin 2007-11-02 10:57:46 UTC
In particular, the following problem should be fixed.
Now it is possible that one and the same thread locks itself in the case when
- some object is being read from persistence (from a single-file storage)
- at this time it requests another read (from another single-file storage)
In the case the 2-nd buffer tries to replace the 1-st one in the cache,
the deadlock occurs (see the stack attached).
The reason is that for the same ReadWriteLock first readLock is aquired, and then the same thread tries to aquire writeLock.

Comment 2 Vladimir Kvashin 2007-11-02 11:00:17 UTC
Created attachment 52347 [details]
Stack fragment that illustrates the previous note
Comment 3 Vladimir Kvashin 2007-11-02 11:01:29 UTC
I believe there are no place in code model that uses persistence in such way; that's why I leave this P3.