I've copied this to jboss-dev because the transaction issues should be
of interest there.
Aaron Mulder wrote:
>
> On Wed, 24 Jan 2001, Toby Allsopp wrote:
> > Anyway, have a look at what I've done and we can go from there.
>
> Looking at ConnectionManagerImpl...
>
> It's not clear to me whether you're trying to handle the case of
> XAResources or non-XAResources. There are a few things that seem
> non-optimal for XAResources, but you specifically decline to handle
> LocalTransactions. I'm a little confused - it seems to me like this
> implementation would be more suited to using LocalTransactions.
Yes, you are quite correct. It is implemented the way it is because I
wanted to implement the XA case, but I couldn't get any real
XA-compliant resources to work - all I had to work with was the Minerva
XADataSourceImpl and friends
> I thought it might be nice to use LocalTransactions for JDBC1/2
> drivers, and XAResources for JDBC2 Optional Package drivers, and forget
> the wrappers. This would suggest two ConnectionManager implementations,
> one using connection sharing and LocalTransactions for normal JDBC drivers
> or non-XA resource adapters, and one using XAResources and no connection
> sharing for XADataSource JDBC drivers and XAResource resource adapters.
I agree. This would be a better approach. I avoided the LocalTransaction
thing because it wasn't obvious to me how to hook this into the existing
transaction context propagation in JBoss.
> Some specific comments:
>
> - You enlist resources with a TX, but the delisting is commented out
It was causing problems with the Minvera wrappers. See my post to
jboss-dev complaining about this.
> - You only return connections to the pool after the TX is done (via the
> Synchronization). With XAResources, you can delist them and return them
> to the pool as soon as they're closed. On the other hand, it would make
> the logic more complicated.
> - It's not really necessary to implement connection sharing for
> XAResources; since separate connections know what TX they're in and can
> share work "on the back end".
Again, this comes back to not having a real XAResourse implementation to
test against. It will go away once local transaction handling is added.
> - The Resource Adapter is allowed to throw a ResourceException when you
> ask for an XAResource if it doesn't support that, as would be typical for
> a current JDBC implementation. You don't handle that in
> allocateConnection (for example, by switching to a LocalTransaction).
You are correct.
> - The spec strongly suggests to me that the app server should have one
> ConnectionManager implementation, which handles all
> ManagedConnectionFactory instances. Is it necessary to tie them 1-to-1
> here?
Not necessary, no. It facilitates having different principal mapping and
pool strategies for different managed connection factory instances.
> - You're synchronizing on the pools a lot - I suspect there's some extra
> overhead there.
You're probably right. I tend towards the "better safe than sorry"
school of thought when thinking about synchronisation. If you can prove
that it's not necessary, please remove it (and document the proof).
> - As far as I can tell, we still haven't solved the problem of a user
> grabbing a connection from a data source *before* they start a
> transaction, or keeping a connection in an instance variable across many
> transactions.
Yes, that's a known limitation. The bean instance needs to keep track of
what connections it has obtained so that they can be enlisted in the
transaction when the bean becomes associated with it. I think
EnterpriseContext is the place to do this.
> On the other hand, the security stuff and pool strategies are
> pretty elegant. I've gone a different way with the pools - I added a
> parameter to getObject in the pool and createObject in the factory so one
> pool could hold connections with different security info, and then a
> validateObject method to the factory to call matchManagedConnections.
> That only locks one object at a time as it looks through the pool, rather
> than locking the whole pool for the duration. You might consider using
> something like that for the SimplePoolStrategy.
I'm sure I had a good reason for grabbing the whole pool. Ah yes - if
the MCF has some sophisticated way of picking the most suitable MC then
it needs to have all the information, not just one at a time. The one at
a time strategy could be an option, though. It depends on how much
contention you're getting on the pool.
> Where's the JDBC Resource Adapter you mentioned?
It's linked to from the documentation
(http://www.jboss/org/documentation/jca_config.html).
Toby.
