David Jencks wrote: >My understanding of Dain's cmp code is that any SQLException will result in >the tx being set rollback only, and basically all work discarded. > >In the new local jdbc wrapper, I've done something about as drastic: if >there is any SQLException from any operation, the connection is discarded >and the connection handle you get is then useless (unless you hold onto it >over a method boundary, then it can get reassociated on the next call). > I had the same questions while writting an adapter for a third party O-R mapping library. The jca spec is rather vague about how exceptions should effect the transaction state. However the intro to section 12 "Exceptions" does state that a resource can throw both system exceptions (where the transaction is rolled back) and application exceptions.
> > >My interpretation of the jca spec is that this is the expected behavior for >a jca adapter. However,... > >1. This breaks at least some code in the test suite, the cts bmp unit test >basically tests for the existence of its table by looking for an exception. > The solution is to always discard a connection handle after any exception. >How much user code is likely to break? Does anyone know what the j2ee spec >says about SQLExceptions (a reference would be great) If this makes JBoss >more spec compliant, do we care if it breaks preexisting code? > This would also break code that tests integrity constraints and handles violations as application exceptions. > > >2. I wrote the wrapper so it would be easy to write an extension for a >specific database that could look at the SQLException content and only >discard the connection if it was actually unusable. If we do this, what >happens to the original SQLException? Do we turn it into a warning? Maybe >this idea of db-specific exception handling won't work. Any opinions? > Why can you not just rethrow the SQLException. It might make sense to turn all exceptions that break the connection into a runtime exception. This would mean they will always be treated as system exceptions. I haven't look at your new code, but how about the following: 1. Each SQLException is passed through a custom exception handler that's added to the adapter in the configuration. 2. The handler indicates if the connection is still good (via a callback?) and returns an exception which is rethrown. > > >thanks >david jencks > > Victor Langelo _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
