When using SFSB in the old fasioned way for long life operations - not as substitution for SLSB for accessing an extended EntityManager within a short-life-period (http-request) - we mentioned several side-effects (not covered in this JIRA-entry) which we could be trace back to the default-poolclass "ThreadLocalPool". So we decided to use instead the "StrictMaxPool"-class.

Now - and this is the bug we found - we could see that the StrictMaxPool's semaphore is not decreased on SFSB-removal which leads to errors upon 1000 (our limit) SFSB has been created. We have mentioned that SFSB's removal does not call the pool's method "release" (The bean should not be reused) but the method "remove" isn't overwritten by StrictMaxPool so the semaphore is never decreased.