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.
