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: Open Resolution: None 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-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 ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
