Aaron Mulder wrote:
>
> When I get a SQLException, it generates a
> javax.transaction.RollbackException, which comes to the client as a
> java.lang.reflect.UndeclaredThrowableException. That doesn't sound
> right...
>
> Aaron
Definitely not right.
I think two things are wrong here:
1)
This exception should not be thrown at the client
if it is not declared. Probably the RMI server code
should catch this and encapsulate the exception in
a ServerException, but other people on the list may
know better.
2)
The RollbackException should not happen, or it
should be caught right at the JTA call that triggers
it. The most common cause of this is that transaction
timeouts are now implemented: The timeout causes an
asynchronous transaction rollback, and if a commit()
is then attempted on the transaction, the
RollbackException is thrown. Even a getStatus() call
just before the commit() is not enough, as it can
race with the timeout if it has not yet happened. The
right thing to do in this case is to wrap the commit()
in a try-catch construct. I do not like it, but that
is how I read the JTA specification.
I do not understand how a SQLException should be able
to trigger a RollbackException. Do you have a stack
trace for this exception?
Best Regards,
Ole Husgaard.
