> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Carlos Pita
> Sent: Thursday, August 03, 2000 3:36 PM
> To: jBoss Developer
> Subject: RE: [jBoss-Dev] TransactionImpl
>
>
> 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.
which would be b.b.b and c.b (just so that folks don't have to blow a few
cells figuring it out :)
quite impressive,
marc
>
> 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
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
>
