From: Masahiko Sawada <sawada.m...@gmail.com> > I think we should not reinterpret the severity of the error and lower > it. Especially, in this case, any kind of errors can be thrown. It > could be such a serious error that FDW developer wants to report to > the client. Do we lower even PANIC to a lower severity such as > WARNING? That's definitely a bad idea. If we don’t lower PANIC whereas > lowering ERROR (and FATAL) to WARNING, why do we regard only them as > non-error?
Why does the client have to know the error on a remote server, whereas the global transaction itself is destined to commit? FYI, the tx_commit() in the X/Open TX interface and the UserTransaction.commit() in JTA don't return such an error, IIRC. Do TX_FAIL and SystemException serve such a purpose? I don't feel like that. [Tuxedo manual (Japanese)] https://docs.oracle.com/cd/F25597_01/document/products/tuxedo/tux80j/atmi/rf3c91.htm [JTA] public interface javax.transaction.UserTransaction public void commit() throws RollbackException, HeuristicMixedException, HeuristicRollbackException, SecurityException, IllegalStateException, SystemException Throws: RollbackException Thrown to indicate that the transaction has been rolled back rather than committed. Throws: HeuristicMixedException Thrown to indicate that a heuristic decision was made and that some relevant updates have been committed while others have been rolled back. Throws: HeuristicRollbackException Thrown to indicate that a heuristic decision was made and that all relevant updates have been rolled back. Throws: SecurityException Thrown to indicate that the thread is not allowed to commit the transaction. Throws: IllegalStateException Thrown if the current thread is not associated with a transaction. Throws: SystemException Thrown if the transaction manager encounters an unexpected error condition. Regards Takayuki Tsunakawa
