Messages inlined... > 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.
I think I want (a) - I know I don't want (b). The problem arrises when I use an XA resource outside of a global tx. (i.e., mark an EJB method NOT_SUPPORTED, and explicitly use setAutoCommit(), commit() and rollback() on my XA JDBC connection). What are the rules regarding local tx access of XA aware resources? According to the JDBC 3.0 spec, this use should be allowed, but I don't know how it fits in with JCA. This usage is failing for me when I fail to explicitly commit or rollback my local tx. I would imagine that these tx should either be committed or rolled back by the server? Maybe not. Regardless, when the application closes a pooled resource, that resource should be in a valid state for the next access. This is where I think my Informix drivers are failing. > What do you think? I don't know - does the JCA deal with any of these issues in a definitive way? -Larry _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
