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
>
>
