commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bojan Vukojevic (JIRA)" <>
Subject [jira] Created: (TRANSACTION-30) Memory Leak in GenericLockManager
Date Tue, 16 Sep 2008 17:00:44 GMT
Memory Leak in GenericLockManager

                 Key: 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);
+                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.

View raw message