Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 120673 - Rewrite repository files cache synchronization
Rewrite repository files cache synchronization
Status: CLOSED FIXED
Product: cnd
Classification: Unclassified
Component: Code Model
6.x
Sun All
: P3 (vote)
: 6.x
Assigned To: Vladimir Kvashin
issues@cnd
repository
:
Depends on: 127727
Blocks: 121530
  Show dependency treegraph
 
Reported: 2007-10-31 16:57 UTC by Vladimir Kvashin
Modified: 2008-04-01 09:53 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments
Stack fragment that illustrates the previous note (4.94 KB, text/plain)
2007-11-02 11:00 UTC, Vladimir Kvashin
Details

Note You need to log in before you can comment on or make changes to this bug.
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo