From: Masahiko Sawada <sawada.mshk@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