I need to think about this a little more, but if we fix it the fix should
be in the jca wrapper, not the tx manager.

Not having yet thought about it more, I wonder if the spec-compliant jca
autocommit behavior would help:  in the absence of a explicit local tx or
xa tx, all operations are performed in their own automatic tx.

Hmm, maybe, maybe not.  The local wrapper I just wrote jumps through some
hoops to provide this autocommit behavior.  Is the problem that you (a)
actually want autocommit behavior outside an explicit transaction? Or that
(b) you want to (implicitly) start a local transaction and have it
committed for you when you start an xa tx?  I think (a) is covered by the
jca spec-compliant behavior, and I think (b) is an error on your
application's part.  

What do you think?

BTW the xa wrapper needs replacing almost as much as the local one did.  I
suspect the local wrapper can mostly be reused, but haven't looked.

thanks
david jencks

On 2002.04.28 20:05:45 -0400 Larry Sanderson wrote:
> I am using the org.jboss.resource.adapter.jdbc.xa.XAManagedConnection
> (and related Factory) to load my Informix XA JDBC connections. 
> Unfortunately I am consistently getting XAExceptions, of the XAER_OUTSIDE
> variety.  I have tracked the problem down to what I think is an Informix
> Driver bug, but I was wondering if we should patch the JBoss transaction
> manager to correct for .
> 
> Here's the issue:  If a connection is used in local-transaction mode, the
> autocommit is set to false, and the user fails to call commit or rollback
> prior to closing the connection, then the connection is put back into the
> pool with the local transaction still open.  Now, if that connection is
> used later within a global transaction, I get the XAException.
> 
> I say that this is an Informix bug because I think most JDBC vendors
> automatically commit on closing within local transactions.  The question
> is, should we put in a call to commit for all closes outside of a global
> transaction?  The code is simple, but can you think of any negative
> repercussions if we do this?
> 
> Thanks
> 
> -Larry
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
> <META content="MSHTML 6.00.2715.400" name=GENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=#ffffff>
> <DIV><FONT face=Arial size=2>I am using the 
> org.jboss.resource.adapter.jdbc.xa.XAManagedConnection (and related
> Factory) to 
> load my Informix XA JDBC connections.&nbsp;&nbsp;</FONT><FONT face=Arial 
> size=2>Unfortunately I am consistently getting XAExceptions, of the
> XAER_OUTSIDE 
> variety.&nbsp; I have tracked the problem down to what&nbsp;I think is an
> 
> Informix Driver bug, but I was wondering if we should patch the JBoss 
> transaction manager to correct for .</FONT></DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2>Here's the issue:&nbsp; If a connection is
> used in 
> local-transaction mode, the autocommit is set to false, and the user
> fails to 
> call commit or rollback prior to closing the connection, then the
> connection is 
> put back into the pool with the local transaction still open.&nbsp; Now,
> if that 
> connection is used later within a global transaction, I get the 
> XAException.</FONT></DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2>I say that this is an Informix bug because I
> think 
> most JDBC vendors automatically commit on closing within local 
> transactions.&nbsp; The question is, should we put in a call to commit
> for all 
> closes outside of a global transaction?&nbsp; The code is simple, but can
> you 
> think of any negative repercussions if we do this?</FONT></DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2>Thanks</FONT></DIV>
> <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
> <DIV><FONT face=Arial size=2>-Larry</FONT></DIV></BODY></HTML>
> 

_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to