Memory Leak in GenericLockManager
---------------------------------
Key: TRANSACTION-30
URL:
https://issues.apache.org/jira/browse/TRANSACTION-30 Project: Commons Transaction
Issue Type: Bug
Affects Versions: 1.2
Environment: Linux 32-bit, JDK 1.5
Reporter: Bojan Vukojevic
Priority: Minor
Generic lock manager has a memory leak. Actually 2 memory leaks. Locks for the transaction are kept in the set. They are removed from the set, but the set is not removed from the map. Although the set is empty at the end of the transaction memory that was allocated for it while it was keeping locks is not released. Java only increases the memory used for the set and never releases it. That is why code must remove the reference to the set so that the whole set is garbage collected and memory is freed.
For the second issue locks are not removed from the globalLocks table because the object that is the key in this table is a resource id, and the code is passing the whole lock object as the key.
Both fixes are shown below:
@@ -329,6 +329,12 @@
GenericLock lock = (GenericLock) it.next();
lock.release(ownerId);
locks.remove(lock);
+ removeLock(lock);
+ }
+ synchronized (locks) {
+ if(locks.isEmpty()) {
+ globalOwners.remove(ownerId);
+ }
}
}
}
@@ -484,7 +490,9 @@
public void removeLock(MultiLevelLock lock) {
synchronized (globalLocks) {
- globalLocks.remove(lock);
+ if(lock != null && lock instanceof GenericLock && ((GenericLock)lock).getResourceId() != null) {
+ globalLocks.remove(((GenericLock)lock).getResourceId());
+ }
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
