Aaron Mulder wrote:
>
> On Wed, 24 Jan 2001, Toby Allsopp wrote:
> > 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.
>
> With a Synchronizer hanging off the existing transaction. When
> the transaction is finished, use the status to determine whether to call
> LocalTrans.commit or rollback. This doesn't work very well if you also
> have XAResources in the transaction at the same time (somewhat worse than
> the Minerva wrapper), but I think we have to trust the user to understand
> that you shouldn't user more than one connector at the same time if one of
> them only supports LocalTransactions.
Ok, that makes sense. I can implement this this week, I think.
> If you want to alter the TM, you could make sure all
> LocalTransactions got committed or rolled back after XAResources were
> prepared but before they were committed, which would be optimal and cause
> no problems for any number of XADataSources and at most one
> LocalTransaction. I think this is what they're discussing in the
> Connector spec section 6.10.
The spec says that LocalTransaction is a performance optimisation, which
seems like a strange way to look at it. The spec also says that there
can be only one resource involved in a local transaction. I think the
real value of local transactions is that the resource adapter doesn't
have to deal with the full (complicated) XA protocol.
> > It was causing problems with the Minvera wrappers. See my post to
> > jboss-dev complaining about this.
>
> Yes, the wrappers definitely don't want to to delist and then
> re-enlist within the same transaction. I'm not sure why you'd want to do
> that though, unless you have several beans in the same transaction. If
> it's really necessary, we could allow them to accept re-enlistment for the
> same Xid...
I made this change and then backed it out because I was having other
problems. For example, when a connection error occurs the connection
should be destroyed, but then rolling the transaction back was causing
problems.
> > Again, this comes back to not having a real XAResourse implementation to
> > test against. It will go away once local transaction handling is added.
>
> Okay, well, let's implement LocalTransactions with a
> Synchronization for now and make this this LocalTrans implementation and
> separate out the XA stuff.
Agreed.
> > > - 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.
>
> Hmmm... This could also be solved with two Maps, but no big deal.
Sure, but why would you want to? You'd need to synchronise access to the
maps in some way. I think having one CM per MCF instance is much
cleaner.
> > 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).
>
> Well, the pool was originally designed to be safe. However, the
> getObject() has introduced a problem, since if you claim *all* the free
> objects then someone else is stuck creating new connections when they're
> not really necessary. If you change that to use the one at a time match
> like below, then you can remove a lot of the synchronizations on the pool.
> More below...
I don't believe that you can safely have multiple threads accessing a
pool without synchronisation. This is not because I have worked out a
scenario where it is provably unsafe, just because I haven't seen a
proof that it is safe.
> > 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.
>
> However, I'm having trouble thinking of when such a sophisticated
> way would really be necessary. I thought the match was basically just to
> match security info on the connections - in other words, a yes/no not a
> ranking. Can you think of when something fancier might be necessary?
If it's as simple as yes/no based on the subject or cxRequestInfo then
it should be better to let the container handle it, as in
GroupBySecurityStrategy. The simpler, one at a time strategy would make
sense in this case.
Toby.
