Well let me just tell you how it works now, and we can compare
notes. When a client calls getConnection() they get a wrapper around the
"real" connection. There's also an XAResource associated with the "real"
connection that registers with the Transaction. When the client calls
close() on the wrapper, nothing happens (other than the wrapper nulling
out its references so it indeed becomes invalid). When the transaction
commits, rolls back, or forgets the XAResource, then the connection is
returned to the pool.
I think this would work in the multi-client case as well. If a
number of clients all get the same connection, and all close it, they're
just nulling out their wrappers and nothing really happens. When the
transaction commits (or etc.) then the connection goes back to the pool.
The one case where this breaks down is where a client keeps a
connection across transactions - if you call commit and then try to do
more. I don't think this should happen with container-managed
transaction demarcation (unless a stateful bean tried to keep an open
connection as part of its state - ugh!). But you could probably do bad
things with a UserTransaction. Perhaps we should add a condition so that
the connection is closed when the transaction is committed (etc.) so long
as all wrappers have been closed...
Aaron
On Wed, 2 Aug 2000, Carlos Pita wrote:
> Hi!
>
> I was thinking about something like:
>
> userTransaction.begin();
> connection1 = dataSource.getConnection();
> // do some stuff with connection1
> ....
> connection2 = dataSource.getConnection();
> // do some stuff with connection1 && connection2 (which are the same
> connection)
> ....
> connection1.close(); // <------- don't put the connection into the
> pool this time.....
> // do some stuff with connection2
> ....
> userTransaction.commit(); // End of transaction
>
> connection2.close(); <------- now return the connection into the
> pool
>
> But a more complex example shows some subtleties:
>
> userTransaction.begin();
> connection1 = dataSource.getConnection();
> // do some stuff with connection1
> ....
> connection2 = dataSource.getConnection();
> // do some stuff with connection1 && connection2 (which are the same
> connection)
> ....
> userTransaction.commit(); // End of transaction
>
> connection2.close(); <------- don't put the connection into the
> pool this time (connection1 is still being used)
>
> userTransaction.begin();
> // do some stuff with connection1
> ....
> connection1.close(); <--- don't return the connection to the pool
> (another connection could be opened for this transaction)
> userTransaction.commit(); // End of second transaction (release the
> connection and put it into the pool) **
>
> ** We should either avoid this case or provide some kind of hook in order to
> let the commit invokation return to the pool the related connection.
>
> I think that a connection should be returned to the pool if:
>
> 1) there are no more fake connections opened for that connection or indeed
> the last is being closed (see below for more on this)
> 2) there isn't a transaction associated with the current thread of control
>
> Another fact is that whenever a thread of control that already has a fake
> connection to a resource manager gets a new fake connection, this new fake
> connection should correspond to the same connection than the first one. If
> the thread of control doesn't have a connection for that resource manager at
> the time of the request, a new one should be given to it from the pool.
>
> Another problem is where does this stuff happen. I think at least close,
> commit and rollback should be aware of this (somewhere, someway).
>
> Carlos.
>
> ----- Original Message -----
> From: Dan OConnor <[EMAIL PROTECTED]>
> To: jBoss Developer <[EMAIL PROTECTED]>
> Sent: Wednesday, August 02, 2000 2:26 PM
> Subject: RE: [jBoss-Dev] TransactionImpl
>
>
> >
> > On 2 Aug 00, at 14:08, Carlos Pita wrote:
> >
> > > > much you can do to work around this. There is no way you can tell a
> > > > Connection which Xid or Transaction it should be associated with -
> there's
> > > > a one-to-one mapping. We planned to set it up so that if you're using
> the
> > > > wrapper, you can only get one connection for any particular Xid.
> > > > The problem with this is that the desired result isn't clear: you
> > > > can either return the same connection object for every request, or
> throw
> > > > an exception for all requests after the first. In the first case,
> it's
> > > > not clear how to handle closing (does the connection close after the
> first
> > > > or last close call?). In the second case, you may be prevented from
> doing
> > > > some legitimate things (using one table in two beans, and you can't
> really
> > > > pass the connection from one to the other).
> > >
> > > I think the first choice is the right one. The second approach is too
> much
> > > restrictive and less transparent for the application. You should return
> the
> > > connection to the pool after the first close that is outside of any
> > > transaction.
> >
> > Hi Carlos,
> >
> > Just a quick thought. I think you should remember that the client
> > "closed" it, and then return it when the transaction completes.
> >
> > -Dan
> >
> >
>
>
