Bugs item #595258, was opened at 2002-08-14 21:41
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=595258&group_id=22866
Category: JBossCX
Group: v3.0 Rabbit Hole
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Bruce Schuchardt (bruceschuchardt)
Assigned to: David Jencks (d_jencks)
Summary: CM hands out connections alreay in use
Initial Comment:
Our JCA connector is for a resource that has a tight
coupling between the JCA connection and a
transaction. A connection cannot be simultaneously
used in two transactions, regardless of any start/end
operations sent to the associated XAResource.
The JBoss connection manager doesn't seem to support
this kind of resource. It blithely hands out the same
connection two concurrently executing threads and
expects the connector to force its resource into a model
that allows this.
With our resource this just isn't possible. The resource
is for an object database. Beans using a connection to
this resource will access persistent objects with the
connection, and those objects are intimately tied to both
the connection and to the connection's transaction (not
the JTA transaction, but the native object-database
transaction).
Handing out the same connection to another thread
allows that thread to access objects in the same object-
database transaction.
I've had exchanges on this subject in the JBoss CX
forum that boil down to "JBoss doesn't support that kind
of resource yet". I'm entering this bug report so the
issue can be tracked for development.
We are currently using a workaround that causes our
ManagedConnectionFactory to notice if a connection
handed to it is in a transaction and, if so, stall until the
connection is out of the transaction before returning it to
the connection manager.
The best solution for us would be for the connection
manager to not pass matchManagedConnections a
connection that is currently being used by a bean.
Another satisfactory solution would be to have the
connection manager pass all pooled connections to
matchManagedConnections so that we could make our
own selection of an appropriate connection.
The local-transaction connection manager does not have
this problem, but we support XA voting and need to be
able to participate in a two-phase commit with a
relational database. Some of our customers would be
satisfied with local-transaction processing, but not all of
them.
----------------------------------------------------------------------
>Comment By: David Jencks (d_jencks)
Date: 2002-09-12 01:26
Message:
Logged In: YES
user_id=60525
This is now ported to jboss 3.2. Bruce reports that it
works with the gemstone adapter so I am closing this.
----------------------------------------------------------------------
Comment By: David Jencks (d_jencks)
Date: 2002-09-09 04:21
Message:
Logged In: YES
user_id=60525
I've refactored the connection managers in cvs head (jboss
4) to modularize the localTransaction and
matchConnectionToTx functionalities. I think your adapter
should work now if you replace
<mbean
code="org.jboss.resource.connectionmanager.XaTxConnectionManager"
name="jboss.jca:service=XaTxCM,name=FirebirdDS">
<mbean
code="org.jboss.resource.connectionmanager.TxConnectionManager"
name="jboss.jca:service=XaTxCM,name=FirebirdDS">
<attribute name="TrackConnectionByTx">true</attribute>
Please test this. If this works I'll consider backporting it
to 3.2.
----------------------------------------------------------------------
Comment By: David Jencks (d_jencks)
Date: 2002-09-04 17:58
Message:
Logged In: YES
user_id=60525
>In order to support the scenario you layed out, the
XAResource would have to switch the physical connection
held by the connection handle to a different physical
connection, BUT it can't do this because XAResources aren't
told what connection handle the container has handed out to
the app. IMO this is one of the gaps between XA and JCA
that make it difficult to adhere strictly to the XA standard
when implementing a connection manager.
I think the jca spec assumes that you are starting with an
EIS that supports the full xa spec, including multiple open
tx on one physical connection (see my previous quote). If
you don't have that, you may have to bend the spec a little.
It's really unfortunate that xa, jta, and jca don't have
actual complete requirements or a usable test suite to find
out what should be supported. If you stop thinking of the
managed connection as being tied permanently to a physical
connection, and have one XAResource for each
ManagedConnection, you can easily associate the
ManagedConnection with an appropriate physical connection
when the XAResource gets a start request.
>There are also pragmatic consequences to switching the
physical connection associated with a handle. For instance,
it will be very easy for a programmer to make a mistake like
this in a bean-managed transaction sequence:
>c = cf.getConnection();
utx.begin();
obj = (domainclass)c.lookup(name);
obj.doABunchOfWork();
utx.commit();
utx.begin();
obj.doMoreWorkForMe();
utx.commit();
>If the physical connection were switched at the
second "begin" operation, the object that was looked
up in
the first transaction would not be associated with the second
transaction's physical connection. Whatever work was done
by "doMoreWorkForMe" would not be committed by the
second transaction. This is a programming error, but it's a
mistake I've seen a lot of people make, and it would reduce
support costs to accomodate it.
I think you could reassociate the object with the
appropriate physical connection, although this would take
some work.
>If the connection manager would pass my MCF all
connections in the pool in matchManagedConnections, so
that I could make my own selection, and/or if the connection
manager would take a null response as meaning it should
create a new connection, then I would be a happy camper.
This is what BEA and IBM do in their connection managers.
The point of my previous example is that there is no
opportunity for the connection handle to be associated with
a different managed connection, so matchManagedConnections
will not be called.
Also, aren't there scalability problems with your approach
of relying on matchManagedConnections?
MatchManagedConnection can't know what the tx context is,
right? so it has to always hand out a physical connection
with NO tx association. So if I do
utx.begin();
for (int i = 0; i > poolsize; i++)
{
Connection c = cf.getConnection();
//cm can't match a connection, because tx association is
//set after mc is matched. You can't get the tx from the
//tm, even if you knew where it was, because I can call
//matchManagedConnections from an arbitrary thread.
c.close();
}
utx.commit();
this will never complete since you ran out of free
connections. This could happen pretty easily through
repeated call to a session bean in one tx.
Although I think the best solution from your point of view
is to decouple ManagedConnections from physical connections
as I have indicated, I think the best solution from JBoss's
point of view is to implement another 2pc connection manager
that caches managedConnections by transaction, as the
Localtx cm does.
----------------------------------------------------------------------
Comment By: Bruce Schuchardt (bruceschuchardt)
Date: 2002-09-04 16:37
Message:
Logged In: YES
user_id=109768
In order to support the scenario you layed out, the
XAResource would have to switch the physical connection
held by the connection handle to a different physical
connection, BUT it can't do this because XAResources aren't
told what connection handle the container has handed out to
the app. IMO this is one of the gaps between XA and JCA
that make it difficult to adhere strictly to the XA standard
when implementing a connection manager.
There are also pragmatic consequences to switching the
physical connection associated with a handle. For instance,
it will be very easy for a programmer to make a mistake like
this in a bean-managed transaction sequence:
c = cf.getConnection();
utx.begin();
obj = (domainclass)c.lookup(name);
obj.doABunchOfWork();
utx.commit();
utx.begin();
obj.doMoreWorkForMe();
utx.commit();
If the physical connection were switched at the
second "begin" operation, the object that was looked up in
the first transaction would not be associated with the second
transaction's physical connection. Whatever work was done
by "doMoreWorkForMe" would not be committed by the
second transaction. This is a programming error, but it's a
mistake I've seen a lot of people make, and it would reduce
support costs to accomodate it.
If the connection manager would pass my MCF all
connections in the pool in matchManagedConnections, so
that I could make my own selection, and/or if the connection
manager would take a null response as meaning it should
create a new connection, then I would be a happy camper.
This is what BEA and IBM do in their connection managers.
----------------------------------------------------------------------
Comment By: David Jencks (d_jencks)
Date: 2002-09-03 23:18
Message:
Logged In: YES
user_id=60525
I think the following sequence of calls has to be supported
by your adapter and a non-pooling connection manager:
TransactionManager tm = ...;
Connection c = cf.getConnection();
tm.begin();//cm enrolls XAResource from newly created mc in
current tx;
c.dosomething();
Transaction tx = tm.suspend(); //cm calls end(suspend) on
xaresource
tm.begin();//new tx, cm calls start(noflags) on xaresource
c.dosomethingelse();
tm.commit();// someone calls end(success) and commit on
xaresource
tm.resume(tx);//cm calls start(resume) on xaresource
c.doyetmorestuff();
tm.commit();//done with first tx.
Did I miss something in the spec?
Note that the current jboss tm and xa cm won't handle this
situation correctly, and as a result you can't pass a
connection as a parameter in an ejb-ejb call. However I
think the spec requires support for this scenario, and it's
the same effect as the situation you don't want to support.
You are also about 80% of the way to what I think of as a
compliant solution: you already pick the physical
connection based on xid, so you just need to decouple the mc
and the physical connection and hook them up based on the
xid supplied to the XAResource. I've always supplied one
XAResource instance per managed connection, but you might be
able to make it work with one XAResource per mcf.
----------------------------------------------------------------------
Comment By: Bruce Schuchardt (bruceschuchardt)
Date: 2002-09-03 22:41
Message:
Logged In: YES
user_id=109768
We seem to have lost our one copy of C193, so I can't look
up the paragraph you're looking at David. Our XAResource is
able to disassociate with the current transaction and operate
on another transaction, but the ManagedConnections cannot
do this. Basically, applications fetch transactional persistent
objects from the MC, and those objects are tied to the
physical connection wrapped by the MC, which supports one
transaction at a time. The XAResource maintains a map
between XIDs and MCs and is able to operate on any
transaction. Each MC has its own "database session",
which I guess maps to what you're calling a physical
connection.
----------------------------------------------------------------------
Comment By: David Jencks (d_jencks)
Date: 2002-09-03 17:29
Message:
Logged In: YES
user_id=60525
I'll look into writing a new connection manager to support
this. However, either I don't understand what the problem
is or your adapter is not xa compliant. On p. 59 of the xa
spec, section 6.2, just before table 6.2, it says:
If a thread suspends its association, it can perform work on
behalf of other transaction
branches before resuming the suspended association.
To me, this means that it must be possible to, on one
managed connection, start xid1, suspend xid1, start xid2,
end xid2, resume xid1, end xid1. Do you have a way of
interpreting this differently? I do not see anything that
indicates that support for end(suspend) and start(resume) is
optional.
----------------------------------------------------------------------
Comment By: Bruce Schuchardt (bruceschuchardt)
Date: 2002-09-03 16:27
Message:
Logged In: YES
user_id=109768
We've had this conversation before. Our adapter runs with
WebSphere and Weblogic, and ran just fine in JBoss 2.4.
BEA recognized the validity of our XA implementation and
fixed a bug in 7.0 to correct their handling of our adapter.
This bug was entered as a follow up to conversations we had
early in the summer and left partially unresolved. Please see
this JBoss forum thread and the email I will attach to this
posting. I think these answer the questions you have.
I can be contacted through my user registration, BruceS, at
jboss.org if you have more questions.
http://www.jboss.org/forums/thread.jsp?
forum=136&thread=16799&message=3725793&q=#3725793
----------------------------------------------------------------------
Comment By: Bruce Schuchardt (bruceschuchardt)
Date: 2002-09-03 16:26
Message:
Logged In: YES
user_id=109768
We've had this conversation before. Our adapter runs with
WebSphere and Weblogic, and ran just fine in JBoss 2.4.
BEA recognized the validity of our XA implementation and
fixed a bug in 7.0 to correct their handling of our adapter.
This bug was entered as a follow up to conversations we had
early in the summer and left partially unresolved. Please see
this JBoss forum thread and the email I will attach to this
posting. I think these answer the questions you have.
I can be contacted through my user registration, BruceS, at
jboss.org if you have more questions.
http://www.jboss.org/forums/thread.jsp?
forum=136&thread=16799&message=3725793&q=#3725793
----------------------------------------------------------------------
Comment By: Bruce Schuchardt (bruceschuchardt)
Date: 2002-09-03 16:25
Message:
Logged In: YES
user_id=109768
We've had this conversation before. Our adapter runs with
WebSphere and Weblogic, and ran just fine in JBoss 2.4.
BEA recognized the validity of our XA implementation and
fixed a bug in 7.0 to correct their handling of our adapter.
This bug was entered as a follow up to conversations we had
early in the summer and left partially unresolved. Please see
this JBoss forum thread and the email I will attach to this
posting. I think these answer the questions you have.
I can be contacted through my user registration, BruceS, at
jboss.org if you have more questions.
http://www.jboss.org/forums/thread.jsp?
forum=136&thread=16799&message=3725793&q=#3725793
----------------------------------------------------------------------
Comment By: David Jencks (d_jencks)
Date: 2002-08-15 00:40
Message:
Logged In: YES
user_id=60525
Well, you are just plain not supporting xa semantics in your
adapter. XA is more than two phase commit, it is also being
able to run several transactions sequentially over the same
connection (which is what jboss is doing).
IMO your adapter will not run in any container that complies
with xa semantics, since one of the things explicitly listed
as possible in all xa references I have seen (xa spec, jta
spec, and jca spec) is running several transactions over the
same connection.
If you wish to make your adapter portable, you will need
(again IMO) to implement an internal pooling scheme between
physical connections (tied to transactions) and
ManagedConnections (which can run several
transactions/connection sequentially). You don't indicate
whether all work on a single transaction needs to go over a
single physical connection or whether work on one
transaction can go over many physical connections. In the
firebird database driver I had this situation and
implemented an internal pooling scheme to push any work
within a given transaction through the physical connection
the transaction first used.
If you would rather keep your adapter non spec compliant, it
would be quite easy (like, 20 minutes of coding) to adapt
the LocalTxConnectionManager to use your ManagedConnection's
XAResource instead of the XAResource implementation in the
ConnectionEventListener.
I would require more arguments in favor of this and more
people requesting it before I would want to include such a
connection manager in JBoss.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=595258&group_id=22866
-------------------------------------------------------
In remembrance
www.osdn.com/911/
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
