Quartz integr.: tx-related bug in LocalDataSourceJobStore?

[immanuel]

There is something I don't understand in LocalDataSourceJobStore. Why does it define getConnection and getNonManagedTxConnection so as they use the same DataSource? In my understanding, one of the two must be an XA datasource, and the other must not, so it seems to me there could possibly be a problem here.

In fact, I think this is the cause of the following problem I have. I want to use quartz in a spring context that is instantiated from an MDB. It seems WebSphere only instantiates the first bean when a message arrives, and does so in a transaction (CMT): while the context starts, quartz initialization code is executed which calls "commit" on the connection which should be non-managed, and this fails with a message regarding global and local transaction (I think, this may even fail before, when the same code executes setAutoCommit(false)).

Isn't this an oversight in the implementation of LocalDataSourceJobStore?

[immanuel]

There is something I don't understand in LocalDataSourceJobStore. Why does it define getConnection and getNonManagedTxConnection so as they use the same DataSource? In my understanding, one of the two must be an XA datasource, and the other must not, so it seems to me there could possibly be a problem here.

In fact, I think this is the cause of the following problem I have. I want to use quartz in a spring context that is instantiated from an MDB. It seems WebSphere only instantiates the first bean when a message arrives, and does so in a transaction (CMT): while the context starts, quartz initialization code is executed which calls "commit" on the connection which should be non-managed, and this fails with a message regarding global and local transaction (I think, this may even fail before, when the same code executes setAutoCommit(false)).

Isn't this an oversight in the implementation of LocalDataSourceJobStore?

No opinions on this? More specifically, what puzzles me a bit is the fact that the bean factory is created in the ejbCreate method, which is called in a transaction context. Shouldn't this be done in the setMessageDrivenContext method which is called before this, and outside a transaction context (but with access to UserTransaction and so on)?