xa

这方面的资料太少了， 最终在一个 IBM的网页 上找到。 首先要先让Oracle 打开XA功能，可以通过以下几步实现 ： 1) 在 SQLPLUS （ ‍ ‍ 一定要用这个工具 ‍ ‍ ） 中，用Oracle 的系统管理员用户 SYSOPER 或 SYSDBA 登录你的数据库（因为这个用户可以获得最多的访问权限）。 2）找到 <Oracle 安装目录>\javavm\install 目录下，有两个脚本 initxa.sql 和 initjvm.sql ，将它们所在的完整路径分别复制到已登录的SQLPLUS环境下（注：在windows下目录分隔符应由"\"改为"/"）执行该脚本。格式如： @d :/initxa.sql 。 注意 ：当执行 ‍ ‍ 这两个脚本时，可能会执行失败，这时需要修改两个Oracle的系统参数（文件放在 <Oracle 安 装目录>\database\init<实例 SID>.ora) ， ‍ ‍ 参数名称 最小值 java_pool_size 12000000 shared_pool_size 24000000 修改完后，需要重新启动Oracle实例才能生效。 3) 设置当前数据库访问用户的权限： grant select on DBA_PENDING_TRANSACTIONS to <当前用户> grant select on pending_trans$

In relation to another post of mine , I realized that there is more we can say on stackoverflow in relation to the Distributed, XA transactions and its internals. Common opinion is that distributed transactions are slow. What are the XA transactions internals and how can we tune them ? First lets put some common vocabulary. We have two or more parties Transaction Coordinator this is where our business logic resides. This is the side that orchestrates the distributed transaction. Transaction Participant (XAResource) this can be any Dababase supporting distributed transactions or some other

I have an application - more like a utility - that sits in a corner and updates two different databases periodically. It is a little standalone app that has been built with a Spring Application Context. The context has two Hibernate Session Factories configured in it, in turn using Commons DBCP data sources configured in Spring. Currently there is no transaction management, but I would like to add some. The update to one database depends on a successful update to the other. The app does not sit in a Java EE container - it is bootstrapped by a static launcher class called from a shell script.