[davidjencks]

I thought i read they fixed the xid issue, if you have a minute to check I'd like to know. If you have an xa driver config for jboss 3 I'd like a copy for the online collection. There may be problems with the xa jdbc wrapper, and I would like to know about them also -- I have no drivers to test it with. Ask if you'd like a suggested starting point.

thanks
david jencks

[bartmann_d]

What about JMS and transactions? Do I need an XADataSource when I'm using DB access and JMS messages within a single transation? I think yes or is it possible to configure JBoss so that the JMS uses the same DB and event the same connection and hence a simple non-XA transaction will also do it?

[davidjencks]

I used to hope that was possible, but it isn't. The jboss mq db persistence actually requires a no-transaction datasource with autocommit. -- that's what the NoTransDS is for in jboss 3 standard setup. They do "xa" by separately committing the messages and meta-info about the xa steps. I haven't seen any tests that the xa features actually work. So, you need xa for the db for sure.

[jardia]

Hi drcharris!

Great to hear that you seem to have got everything working well.

I was wondering if you pls could have a look at the INET news server and let me know if you can make more sense of what Volker is trying to say. In particular when he says "But the XDataSource is only a emulation".

>> news.inetsoftware.de --> jdbc-mssql-opta --> When do i need an XADataSource?

Interesting comments about the changing the TM. I'm currently testing with Opta415 and the default TM and yes i have seen the Xid problem, but then it goes away, very strange.

I would also be interested about anything more you could add to the SFSB-locking-scenario you alluded to. I think that a SFSB in our system is one of the main culprits of our database locks...any input would be much appreciated!

Maybe we could compare config files (jboss.jcml, standard-jboss.xml).
Any specific SQLServer2000 settings.
Bean transaction attributes.

cheers
oliver

PS: You in London? We're in smithfield...

[drcharris]

(to davidjencks)

I don't have a JBoss 3 XA datasource config since I'm working exclusively on 2.4.3 at the moment (we're approaching production release and I don't have the time to get dirty with 3.0 during working hours).

That said, I'm at the London training next week so should be much better informed about RH after that - I can try and rig a working environment up at home. Do you have a minimal application that uses two resource managers I can deploy straight off? If not I can write one.

There was an earlier Xid issue which was a total show-stopper for the opta2000 driver. That was fixed in 4.11. The problem I have only show up if I use the ordinary tm instead of Tyrex. Just to clarify - Tyrex is for distributed transactions (inter-vm) right? And the ordinary tm will handle coordinated transactions intra-vm? I'd like to be able to use the ordinary tm since currently we are completely intra-vm and I suspect it's a lot faster.

[drcharris]

(to jardia)

I don't have nntp access from here so I'll try and look over the weekend at the issue. It's possible he is talking about the jboss.pool.XADataSourceImpl which is an emulation - without reading the full post I can't be sure.

The inet boys do know what they're talking about, though - they've been really helpful with any problems we've had.

The SFSB stuff is pretty off-topic here, but briefly - I filed a bug about it but don't know what needs to be done to fix it. It happens when a method inside an SFSB calls setRollbackOnly() and either returns a value normally or throws an application exception. The bean is then unusable for subsequent calls and you get 'locked < 0' errors on the server, followed by 'no concurrent access' exceptions. My current theory is that it's getting unlocked too many times and the reference count for that bean is going negative. There's some locking code in the EnterpriseContext class which to me looks suspicious, where the test isLocked() basically looks for the ref count being != 0 instead of >0. Again, it's something I want to look at as soon as possible.

I'll send you my jboss conf files separately.

(btw - we're on Chancery Lane!)

[drcharris]

OK I've had a look on the newsgroups and they mention having to have access to the master database on the SQL Server. We do use this approach - your database user needs public, owner, datareader, datawriter permissions on the master database plus whatever other database you use.

(for others - a SQL Server database is somewhat equivalent to an Oracle tablespace)

[davidjencks]

The first problem with xa in jboss 3 is to get the wrapped driver to work at all. AFAIK no one has actually used the jca-xa wrapper. Once it deploys and works for one db we can look at checking proper xa semantics.

I will try to come up with a suggested starting point for a ConnectionFactoryLoader using the jca-xa wrapper.

The jboss "fast" tm will execute transactions spanning several resource managers (dbs) from one vm, and if one prepare fails handle the tx appropriately. However, it does no logging (that's why it is fast) so if the tm fails during prepare or commit no automatic recovery is possible (the tx participants are not recorded. If you can figure them out by other means you might be able to recover by hand). Of course, this is fine for 1pc tx on one resource manager.

I haven't looked but my understanding is that Tyrex does the appropriate logging to enable automatic recovery.

[drcharris]

I've done some more digging.

Jardia - you are right about the contents of com.inet.tds.XDataSource. It is an emulation of true XA and according to inet doesn't implement recovery properly.

Inet recommend, for true XA, using the DTCDataSource class which is JTA-compatible and works with Microsoft's DTC. This only appears in version 4.15 or greater of the driver.

I've tried using the trial version of this in JBoss through XADataSourceLoader but cannot get it to work with the JBoss tm. I'll post more on this once our support contract with inet is renewed. I'll also try doing it through JCA wrapper but preliminary attempts also failed here (I'm on 2.4.5).