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 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
