I\'m getting the following exception in my log when I try to perform an XA transaction:
javax.transaction.xa.XAException: com.microsoft.sqlserver.jdbc_SQL
It's been a while since I've used Java with SQL server, but just off the bat I noticed something in your T-SQL that might not have behaved the way you wanted. The snippet:
use master GO;
EXEC sp_addrolemember [SqlJDBCXAUser], 'MyUserName' GO;
Only applies the [SqlJDBCXAUser] to your username in the master database. If your database is in another instance, you will also have to add the role there. The other I'm assuming was a typo ('sp_gratdbaccess' should be 'sp_grantdbaccess').
I'm assuming your 'xa_install.sql' scripts that you had to run in all participating servers ran successfully, and you received no error messages? Examine the script for the roles it defines, just to make sure what you are typing matches what is needed.
Update:
Just some sanity checks:
Microsoft is ambiguous when it calls things an "Instance", particularly because they apply it to database instances (your database) as well as SQL Server instances. One physical server can have multiple copies of SQL server running at the same time listening on different ports. Each of these would have its own Master database instance. By the context of the other statements (i.e. the XA transaction support lives in the master database), they are talking about every copy of SQL Server you have running. If your app's database is spread accross 4 instances (installations) of SQL Server, you have to perform the XA installation steps on all four installations.
The last step to make sure that the roles took, and are applied to your system properly, open up the master database with the management console. You want to make sure your user is in the Databases/master/Security/Users folder, and that it has the SqlJDBCXAUser role enabled (checkbox for the role).
Next, go to the offending stored procedure that is complaining, and make sure that any security settings include the SqlJDBCXAUser role. The role names shouldn't be case sensitive (as SQL itself is not), but it wouldn't hurt to make sure the role case is the same case--just in case.
If that fails, also run the 'xa_install.sql' script in your MyDatabase instance. I personally hate this ambiguity, but it very well could be what they mean. But before you do that, make sure you don't need any hot fixes or have a configuration where it won't work right. Undoing something a complicated SQL script does can be a major pain. That's why I suggest doing this last.
We only had to do the following:
USE [master]
GO
CREATE USER [UserName] FOR LOGIN [UserName] WITH DEFAULT_SCHEMA=[dbo]
use [master]
GO
GRANT EXECUTE ON [dbo].[xp_sqljdbc_xa_commit] TO [UserName]
GRANT EXECUTE ON [dbo].[xp_sqljdbc_xa_end] TO [UserName]
GRANT EXECUTE ON [dbo].[xp_sqljdbc_xa_forget] TO [UserName]
GRANT EXECUTE ON [dbo].[xp_sqljdbc_xa_forget_ex] TO [UserName]
GRANT EXECUTE ON [dbo].[xp_sqljdbc_xa_init] TO [UserName]
GRANT EXECUTE ON [dbo].[xp_sqljdbc_xa_init_ex] TO [UserName]
GRANT EXECUTE ON [dbo].[xp_sqljdbc_xa_prepare] TO [UserName]
GRANT EXECUTE ON [dbo].[xp_sqljdbc_xa_prepare_ex] TO [UserName]
GRANT EXECUTE ON [dbo].[xp_sqljdbc_xa_recover] TO [UserName]
GRANT EXECUTE ON [dbo].[xp_sqljdbc_xa_rollback] TO [UserName]
GRANT EXECUTE ON [dbo].[xp_sqljdbc_xa_rollback_ex] TO [UserName]
GRANT EXECUTE ON [dbo].[xp_sqljdbc_xa_start] TO [UserName]
GO