jakarta-eedatasourcejtaxaejb-timer

XA non XA datasource in WebSphere


I am currently working on a web application running on a mutualised WebSphere. This application uses a datasource (shared with other applications) and persistent EJB Timer.

Since the EJB Timer are persistent, WebSphere uses its own datasource in order to persist the EJB Timer state into the database. (Used for internal management of WebSphere)

Application's EJB Timer call DAO my "create method".

All are managed with JTA transactions.

I would like to find the best "strategy" to apply regarding datasources. After several searches on the Internet I am still in the dark.

How to configure datasources?

In my opinion, all datasources should be in non XA...

What is the best practice when we using datasource in a mutualised environment, is it necessary to use one datasource (pointing to the same DB) per application or to have only one datasource per DB?

Thanks a lot :)


Solution

  • I'm not certain what you mean by 'mutualised' WebSphere, but I'll assume you mean an instance of the app server with multiple applications running. Your questions:

    Should two datasources be used in XA? Not necessarily two datasources, but two or more resources in general. Resources other than datasources can participate in XA transactions. In general, if a transaction doesn't involve multiple database resources, you want to use an non-XA datasource to execute that transaction. Is it possible to use a non-XA datasource for the management of my EJB Timer and XA datasource for the processing done in my EJB ? Yes, it is. You also stated Since the EJB Timer are persistent, WebSphere uses its own datasource... It is true that the default datasource is used by default, but you are free to configure the ejb timer service with another datasource. Is it necessary to use one datasource (pointing to the same DB) per application or to have only one datasource per DB? It is not required to use a DS for each application, but it may be necessary depending on your requirements. There is no easy best practice because of the complexity of an enterprise environment. Obviously, if your data is stored in multiple backends, you'll need multiple datasources. If all of your data is stored in a single backend, using a single DS may make sense.