[jrf-user] Pooling bug and fix for JRF 1.X

[Mark E. <me...@pe...>]

I discovered a bug with connection pooling in JRF 1.6/1.7 and have a fix
for the problem. For the benefit of other JRF users still using version
1.X, I'll give an overview of both the bug and my fix.
 
The problem is that it's possible for a domain instance that extends
AbstractDomain to use a jdbcHelper already in use by some other domain,
resulting in a conflict and an exception.  The fix ensures that only one
domain at a time can use a particular jdbcHelper.
 
Typically each AbstractDomain instance using pooling will grab a
jdbcHelper from a jdbcHelperPool, do a query, and then release the
jdbcHelper back to the pool.  The AbstractDomain instance remembers the
jdbcHelper that it last used by storing it in the field variable
i_jdbcHelper, even after releasing it back to the pool.  If you perform
another query using the same AbstractDomain instance, the domain will
try to use that same jdbcHelper under certain circumstances rather than
getting one from the pool.  But since that jdbcHelper was returned to
the pool after the previous query, it's possible that some other domain
(i.e. process) in a multi-threaded application already grabbed and is
using it while it's being reused by the first domain.  This is the
problem.
 
You can avoid this conflict by setting jdbcHelper to null in
AbstractDomain after each call to getJDBCHelper() in the public
interface routines.  This will force the domain to get a jdbcHelper from
the pool for the next query rather than reusing the previous one.  So
for example here is the original code for the routine find(Object
pkOrPersistentObject):
 
            return this.find(pkOrPersistentObject,
this.getJDBCHelper());
 
And here's the new code:
 
PersistentObject pObj = this.find(pkOrPersistentObject,
this.getJDBCHelper());
            i_jdbcHelper = null;
            return pObj;
 
You'll need to make this change in each of the 12 routines declared
public in AbstractDomain that call getJDBCHelper().  Hope this helps,
 
Mark Ellis
PeopleAnswers