The XA Oracle driver is not able to manage DDL operations which result in transactions commits in a JTA transaction.
[Customer] is facing HHH-1361/JBPAPP6-1628.
This issue seems fixed by HHH-1361, making dropTemporaryTableAfterUse
return false to Oracle Dialect. However testing the scenario with
hibernate-core-4.1.3 we still can see exceptions like:
insert
into
HT_IAP_PVR_L_RECORDINGS
select
lpvrrecord0_.RECORDING_ID as RECORDING_ID
from
IAP_PVR_L_RECORDINGS lpvrrecord0_
where
lpvrrecord0_.EQUIPMENT_ID='equip'
Hibernate:
delete
from
HT_IAP_PVR_L_RECORDINGS
javax.persistence.PersistenceException:
org.hibernate.exception.SQLGrammarException: ORA-00942: table or view
does not exist
at
org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1372)
Sounds like Hibernate is still trying to delete the HT and commit the
DDL in that session (which is not allowed by Oracle Driver), even though
the dialect says to not do that. I've also tried a custom dialect,
flagging performTemporaryTableDDLInIsolation as true and as false but
without success.
A workaround which works is changing the application to a non-xa
datasource, which is not acceptable to customer, they must use XA (the
issue only happen when used XA).
Another solution is pre-creating the temporary table (since temporary
tables are like regular tables to Oracle). I've tested here and it
works, but customer said that it is not practicable and safe to
production environment.
So, they are expecting a patch. Attached here there is a test case which
reproduces the issue. It is a Eclipse project with dependencies already
bundled. Running the jUNIT it will setup a XA datasource using Bitronix
and run the test. The unique change should be made in the class
"OracleXaDatasourceHelper" to define an appropriated Oracle
user/password and URL.
Please let me know if there is something wrong in the test case that
justify the issue. Also, if you see another workaround that can be
applied instead of a patch will be welcome too.
Major