Thread-safe problem with PersistenceBrokerThreadMapping

[Brian Devries <bd...@intraware.com>]

Hi all,

I've noticed a thread-safe problem in that way the
PersistenceBrokerFactoryDefaultImpl class handled the thread-broker mapping.

The result I've noticed is that threads can potentially grab brokers
from the thread map even after the broker has been returned to the pool
which can create multiple threads acting on the same broker and strange
results.

The problem is that when a pooled broker is created, its wrapped in a
PoolablePersistenceBroker object so the pool can manage it. Then this
wrapped broker is passed to the PersistenceBrokerThreadMapping class as
the default broker.

However, in the close method of the PersistenceBrokerImpl, the call to
unset the broker as the default for the thread passes a reference to
itself, rather than the PoolablePersistenceBroker that is wrapping it.
The result is that the broker is still associated to the thread even
after it is also returned to the pool. I then, was seeing some strange
things around two threads trying to use the same JDBC connection and
PreparedStatements with the Informix driver.

To fix this, I changed the PersistenceBrokerFactoryDefaultImpl to use
the following code to associate the broker to the thread:

if(broker instanceof DelegatingPersistenceBroker)
{
     PersistenceBrokerThreadMapping.setCurrentPersistenceBroker(pbKey,
     (DelegatingPersistenceBroker)broker).getDelegate());
}
else
{
     PersistenceBrokerThreadMapping.setCurrentPersistenceBroker(pbKey,
broker);
}

This way the underlying broker is associated with the thread rather than
the wrapped version.

-Brian

-- 
Brian DeVries                   Sr. Software Engineer
mailto:bdevries@intraware.com   http://www.intraware.com
Voice: 925.253.6516             Fax: 925.253.6785
--------------------------------------------------------
Intraware... The leading provider of Electronic Software
              Delivery and Management (ESDM) Solutions