J

JDBM

Settings | Report Duplicate

1

I Use This!

Activity Not Available

Commits : Listings

Analyzed about 1 month ago. based on code collected about 1 month ago.

Commit Message	Contributor	Files Modified	Lines Added	Lines Removed	Code Location	Date
Jan 06, 2024 — Jan 06, 2025 Showing page 1 of 8 Search / Filter on:
Fix high order bit issue with getLong	trumpetinc	More...				over 16 years ago
Adjust test to pick up high order bit issue with getLong	trumpetinc	More...				over 16 years ago
Fix resource leak when a BTree is completely emptied	trumpetinc	More...				almost 17 years ago
Add Buildfile	Alex Boisvert as boisvert	More...				almost 17 years ago
Removed use of Java 5 autobox feature.	thompsonbry	More...				over 18 years ago
Since objects are installed on the database when they are evicted from the hard reference cache, any object not on the hard reference cache MUST be clean. The dirty flag was removed from the weak reference cache entries. A get() on the weak reference cache always set the dirty flag to false when installing an object into the hard reference cache. Note that put() still installs whatever value is given for the dirty flag onto the hard reference cache and that is how objects get marked as dirty.	thompsonbry	More...				over 18 years ago
Initial commit of a feature for page at a time installs of buffered records. This is a prototype feature. I find that it works for our application in combination with the weak reference cache. There are still some remaining bugs that need to be ironed out, including one in the historical record at a time allocation (allocNew), where the scan of records on a page can run past the end of the page. I also plan to develop a record clustering feature based on this. This feature is off by default but can be enabled using a RecordManagerOption.	thompsonbry	More...				over 18 years ago
Added some javadoc.	thompsonbry	More...				over 18 years ago
Javadoc cleanup.	thompsonbry	More...				over 18 years ago
Added hashCode() and isZero(). Update equals() to use a reference test first.	thompsonbry	More...				over 18 years ago
Modified to use unique seed on each run, make an inner class static, and modified to set the root cause on thrown exceptions.	thompsonbry	More...				over 18 years ago
Removed interleaved blank lines.	thompsonbry	More...				over 18 years ago
Added more debugging information for an exception.	thompsonbry	More...				over 18 years ago
Removed outdated comment.	thompsonbry	More...				over 18 years ago
Fixed autobox of 0L to null (java 1.4 compatiblity change).	thompsonbry	More...				over 18 years ago
Fixed some problems with the MRU cache. Consider the following scenario, which could occur either during a cache eviction or during a commit. An object uses extSer to generate a classId as part of its serialization, which in turn caused extSer to invoke recman#update(). This results in the cache entry for extSer being marked as dirty. 1. commit. If this occurred during a commit and the extSer cache entry had already been scanned, then the change in the dirty flag was missed and the updated state of the extSer object was not installed into the database. This was fixed by changing the MRU elements() and entries() methods to return Enumerations ordered from LRU to MRU. (The old behavior used the Enumeration of the inner hash table�s entry set, which was essentially a random visitation.). Traversal from LRU to MRU has the advantage that we are chasing a reference chain (this is faster), that we are installing objects into the database in the same order that they would be evicted from the cache, and that any objects which get touched during the traversal will naturally appear in the MRU position and therefore be re-visited, thereby ensuring that we do not loose any updates. In addition, the MRUEnumeration class now listens for and handles concurrent modifications during traversal. This ensures that changes in the MRU ordering during a commit operation can not cause cache entries to be skipped. 2. eviction. If this occurred during a cache eviction, then the MRU was failing to correctly handle the reentrant invocation of its put() method. This resulted in the reentrant put() failing to install its object into the cache (in this case, the extSer object was not being installed into the cache). This was fixed by testing for reentrant invocation of put() and allowing a temporary over capacity state for the cache rather than evicting objects to maintain the cache at capacity. The cache is then reduced to capacity by purging LRU members once the stack frame has popped back to the top-level invocation of put().	thompsonbry	More...				over 18 years ago
Added dependency on bundled extser JAR to build.xml.	thompsonbry	More...				over 18 years ago
Bringing the new SF CVS server uptodate with commit of lost changes.	thompsonbry	More...				over 18 years ago
Refactors extSer support out of jdbm and bundles the extSer feature based on the CognitiveWeb extSer module.	thompsonbry	More...				almost 19 years ago
Refactors extSer support out of jdbm and bundles the extSer feature based on the CognitiveWeb extSer module.	thompsonbry	More...				almost 19 years ago
Jiggled some constants to get the test to run under another JVM with a different heap size.	thompsonbry	More...				almost 19 years ago
Fixed bug in the integration of the weak and soft cache options with the CacheRecordManager. The underlying problem is that jdbm's CacheRecordManager class was inserting intermediary objects rather than application objects into the WeakCache. Since the intermediary objects were not held by anyone, the weak cache enties for those objects were quickly cleared. As soon as the application objects were evicted from the internal MRU, a subsequent request for an object already in memory would result in a duplicate object entering memory.	thompsonbry	More...				almost 19 years ago
Added test which can be used to demonstrate a failure in how the jdbm CacheRecordManager is setup. The test is named TestWeakCache#testL2RecoveryWithHardReference(). You have to edit the code to run the test. There are two conditions. In one, the objects are inserted directly into the cache and the test succeeds. In the other, the objects are first wrapped with a hard reference and then inserted into the cache and the test fails. The demonstrates that application objects must be directly inserted into the cache, not objects holding hard references to application objects. The CacheRecordManager needs to be rewritten to no longer use a CacheEntry object which wraps a reference to the application object.	thompsonbry	More...				almost 19 years ago
Rolledback to JDK 1.4. The use of the 1.5 Long factory mechanism can provide a performance boost, but we will wait to introduce it until jdbm2.x.	thompsonbry	More...				almost 19 years ago
Fixed NPE if tree is created and immediately deleted without adding data	trumpetinc	More...				about 19 years ago
Added delete capability to BTree	trumpetinc	More...				about 19 years ago
Enabled the remove() operation on CacheAll. This operation is invoked when a persistent record is deleted, so it makes sense to allow removal from the cache at that time.	thompsonbry	More...				about 19 years ago
Added test suite and corrected some javadoc and debug statements.	thompsonbry	More...				about 19 years ago
Added support for "weak" cache. This cache type exhibits better performance until the commit and a faster commit, presumably since the garbage collector is making fewer bad decisions about which objects to finalize. The store file size is not effect by this cache choice (soft vs weak).	thompsonbry	More...				about 19 years ago
Added core dump and heap dump wildcards and log file wildcards to .cvsignore.	thompsonbry	More...				about 19 years ago

←
1
2
3
4
5
6
7
8
→