Change Datasource Unit-Name during runtime problem with AS7 - General discussion -

[haukegulich]

Hello everyone,

I have a general design question for our interface application we develop with EJB deploying on AS7.

We have some company interfaces (like XML or CSV interfaces) who export some data from the database to those files. The is a standard interface for almost each customer of ours.

We do have a data-center where more then 50 customers host our application and there we need to install the AS7 application server with this default interface.

Each customer has its own database inside the data-center! We define each customer with its database in the persistence.xml and give them a unique unit-name.

Now we create several instances from our standard EJB interface class (for each customer one instance) who exports their data.

The problem is, how can I change the datasource unit-name at the annotation for the entity-manager? I know it is not possible to change the value of an annotation, but I found some

topics with an EntityManagerFactory passing the unit-name. If I try that, I get an

Schema export unsuccessful: java.sql.SQLException: You cannot set autocommit during a managed transaction!

So what we need is the create dynamically the entity-manager depending on the customer.

I can not post any examples because we are only testing and do brain-storming about that issue.

Would it be possible to ignore the persistence.xml datasources and create a new one during runtime? we could store the connection data in a global database for each customer.

Many greetings,

Hauke

[sfcoy]

To be clear:

You have a single instance of JBoss hosting your application, which services around 50 customers.

The data for each customer is stored in their own private database.

Is that right?

What kind of database is it?

Are all the databases hosted by the same database server?

[haukegulich]

The actual state of our system which can't be modified:

Each customer has its own database.

I would say that 95% have the same database structure. Maybe one or two customer have additional fields / table. The other customers will get the database update later.

The all use the same database: Informix (I didn't know Informix before I started working in that company). My testing system is based on several MySQL databases. I think that shouldn't make any differences?

The databases are hosted on three different server.

Each customer could have their own interfaces to external systems we developed for them.

Each customer could have standard interfaces to / from external system we developed for everybody.

The goal of the system should:

We want a system where inside a central database all information will be stored, which customer has what kind of interfaces activated and how they are set up. If it's an

own interface only for one customer, we could do something like this:

@PersistenceContext (unitName = "DS_customerA")

EntityManager em;

But we need a solution for our default interfaces we have once developed and everybody could use. We can not use a static unitName. We need to change that in whatever

is stored in the central database to the customer name.

My thoughts about the interface-system:

In the beginning we will start with a single JBoss app server. Later we might add a second JBoss and seperate the customers to one of the jboss instances (depending of the traffic and the usage)

I thought that I need to add for each customer one datasource with their database connection setting to the persistence.xml and create with the EntityManagerFactory a new EntityManager where I could pass the

datasource name.

Sorry for my english but hopefully you get the point of my post.

Many greetings,

Hauke

[ctomc]

Hi,

what your are trying to create is quite possible and if i remember correctly a firend of mine had this kind of a setup for their application.

But they ware using seam 2 to create this...

Given technology you are using i would recomend would go with combination of EJB + CDI beans.

What you esensaily need is producer for providing EntityManager which you then inject whereever you need it.

that means you won't be doing injection via @PersistenceContext in your beans but via @Inject

which can be furter customized with qualifiers...

Take a look at seam(3) persistence module where something similar is done, but just for one peristence context.

you could just take that example and replace field producer with method producer that will return right EntityManager given your context.

--

tomaz