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 32089 - Reimplement the caching framework.
Summary: Reimplement the caching framework.
Alias: None
Product: obsolete
Classification: Unclassified
Component: vcscore (show other bugs)
Version: 3.x
Hardware: All All
: P1 blocker (vote)
Assignee: Martin Entlicher
Depends on: 44216
Blocks: 26096 28223 28774 32193 32345 34137 34153 34280 34772 34776 34795 36643 36928 37679 39817 40423 41012 41141 41715
  Show dependency tree
Reported: 2003-03-18 13:58 UTC by Martin Entlicher
Modified: 2005-05-06 09:31 UTC (History)
4 users (show)

See Also:
Issue Type: TASK
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Martin Entlicher 2003-03-18 13:58:54 UTC
According to issue #32065:
It is not reasonable to write data to disk in
ReferenceQueue handler. The handler shlould do
fast cleanup, not backup of "lost" data. What if
the IDE was ended without releasing (and thus
saving) the data?
Comment 1 Martin Entlicher 2003-08-01 15:18:00 UTC
I'm generalizing this task and scheduling to NetBeans 4.0.

There are more problems connected to the caching framework that should
be addressed in the next release.

These are mainly improved testeability and usability of
org.netbeans.modules.vcscore.cache.* package, that should re-design
the public classes and methods to make implementations easier and
better distinguish provided functionality and functionality, that is
expected from the implementations. This will also improved
testeability. It should be possible to write unit tests.

Also performance should be improved. Access to disk cache should be
minimized. It must be paid atention not to do more work, that is
really necessary. Ideally, performance tests should be written.

If a disk cache is corrupted, it should recover automatically (clean
the garbage and force refresh to have fresh data).

Adding depending issues.
Comment 2 Martin Entlicher 2003-08-19 16:59:06 UTC
Starting to work on it...
Branch "cache_32089" created in vcscore module (with
"cache_32089_base" as the base). The re-design will be made in that

Comment 3 Martin Entlicher 2003-11-14 10:48:46 UTC
Branch cache_32089 was created from prj40_prototype branch. Therefore
this branch is unusable in the main trunk (it was not intended to do
this in trunk when I started to work on it).

But now, the cache redesign is necessary for 3.6 release. Therefore
I've created a new branch cache_32089_1 (with base tag
cache_32089_1_base) from current trunk in vcscore module.

The development of the new caching framework is moved to cache_32089_1
Comment 4 Martin Entlicher 2004-01-05 14:01:45 UTC
Unfortunately, the cache redesign is not doable in 3.6 timeframe. We
have feature freeze at the end of this week and there are still some
UI issues pending.
Therefore I'm rescheduling this to promotion D.
Comment 5 Antonin Nebuzelsky 2004-03-18 11:44:53 UTC
Martin, what's your current plan with regard to the cache
reimplementation? Do you have an idea if/when it will be available for
promo-D? Thanks.
Comment 6 Martin Entlicher 2004-05-20 17:12:45 UTC
Unfortunately it will most likely not be implemented into promotion-D.
We are in a stabilization period and this is considered to be a risky
change in this timeframe. It's scheduled for promotion-E.
Also API review is in progress (issue #43637).
Comment 7 _ pkuzel 2004-09-02 12:25:37 UTC
FYI (copy from issue #43637)

I'm working on cache implementation simplification. It uses Map like
  + void set(FileKey, FileStatus)
  + FileStatus getCached(FileKey)
  + void add/removeListener(l)

and utility methods:
  + FileStatus get(FileKey)  // may connect to repository
  + FileStatus getFresh(FileKey) // connects and caches result

and utility class IgnoreList   
  + bool isIgnored(FileKey)

There is also AbstractFileSystem integration method that allows to
trace FileObject's lifetime (and derived FileKey lifetime).
  + FileReference createFileReference()

FileKey is currently FileObjct itself but it seems to lack uniquess
and I'll replace it by FileUtil.toFile(fo).getAbsolutePath().
Prototype is being developed in vcscore.turbo package.

If it prove successfull it'd affect this issue a lot.
Comment 8 Martin Entlicher 2005-01-05 19:35:31 UTC
The cache was finally redesigned and implemented according to document.
Committed to trunk today by Petr Kuzel.