Hi!
I will put my previous thoughts in another words:
a) If a thread of control asks for a new connection:
a) If it already has one (or more) real connections, the real connection
associated with the new fake connection should be the same as the one
associated with the previous ones.
b) If it has no fake connection yet, a new one should be returned which
is associated with a new real connection (taken from the pool).
b) If a thread of control closes a connection:
a) If it has more fake connections yet, the real connection should not
be returned to the pool.
b) If this is the last connection:
a) If the thread is in a transaction, the real connection should
not be returned to the pool.
b) If it is not in a transaction, the real connection can be
returned to the pool.
c) If a thread of control commits or rollbacks (and the hooks could be in
the XAResource wrapper):
a) If the thread has no fake connections, the associated real connection
(if there is one) can be returned to the pool.
b) If the thread has fake connections yet, the real connection should
not be returned to the pool.
I think we agree in a.a, a.b, b.a, b.b.a and c.a, but not in the other 2
points.
Carlos
----- Original Message -----
From: Aaron Mulder <[EMAIL PROTECTED]>
To: jBoss Developer <[EMAIL PROTECTED]>
Sent: Wednesday, August 02, 2000 7:44 PM
Subject: RE: [jBoss-Dev] TransactionImpl
> 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
> > >
> > >
> >
> >
>
>
>
