On 2 Aug 00, at 18:44, Aaron Mulder wrote:
> (unless a stateful bean tried to keep an open
> connection as part of its state - ugh!).
Ugly +1. But legal.
> 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...
Yes (if what you mean by 'closed' is 'returned to the pool.').
-Dan
>
> 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
> > >
> > >
> >
> >
>
>
