This content has been marked as final.
Show 3 replies
-
1. Re: JBossManagedConnectionPool.getPool
adrian.brock Dec 19, 2005 9:42 AM (in response to adrian.brock)The other "side-affect" is the track-by-tx transaction local.
-
2. Re: JBossManagedConnectionPool.getPool
adrian.brock Dec 19, 2005 9:58 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
Again, this could do with "putIfNotPresent" construction semantics on a concurrent map.
However, there is a complication in that creating a new sub-pool currently has side-affects.
i.e. registering the subpool with the idle remover.
This will need to be separated into an initialization operation once the pool
has been established as the one to use (rather than just thrown away because
it is duplicate construction request).
Let me reword this so it makes sense :-)
You can only use putIfNotPresent semantics if discarding the duplicate
instance does not cause problems.
In this case, the internal pool is registered with the idle remover in its constructor.
Which must either be undone or done after the "pool to use" is established.
The option of initalizing lazily can only work properly if it is "temporarily optional"
for the correct behaviour of the pool.
e.g. This race condition
Thread 1: Establish pool
Thread 2: Use created pool
Thread 1: Complete initialization of pool
In this case, the registration with the idle remover isn't important for Thread2
to use the pool.
The track-by-tx context is important, so it would be better if this moved
into a single context object that is added to one map (rather than two separate maps).private class InternalPoolContext { InternalManagedConnectionPool subPool; TransactionLocal trackByTx; }
-
3. Re: JBossManagedConnectionPool.getPool
adrian.brock Dec 19, 2005 1:27 PM (in response to adrian.brock)JIRA issue: http://jira.jboss.com/jira/browse/JBAS-2578