CODEWITHSUNDEEP
postgresqljakarta-eejpaglassfishejb-3.0
Joe Javac
Joe Javac

Reputation: 111

JavaEE changing DB schema runtime for SaaS application

i am developing a SaaS application by using JavaEE technologies (JPA, EJB, ..)

for multitenancy, i chose 'Shared Database, Separate Schemas' approach and designed the DB (PostgreSQL) like that

basically what i need to do is changing the default schema for user sessions in the application so that users can get their own data from the right schema

my business logic is implemented with EJB (Container-managed) and the app server is glassfishv3 so in my EJBs i am just injecting the EntityManager like this

@PersistenceContext(unitName="DBNAME")
private EntityManager em;

and leaving the transaction management to the glassfish

i tried to write @PostConstruct callbacks for Stateless EJBs injecting DataSource but getClientInfo() returns null somehow so i can not even see the default schema. The reason why i injected DataSource was because i thought i have to do some low-level stuff to specify the schema.

i know if i manage the transactions in the application instead of leaving them to the app server, i can change the EntityManager values through EMF easily but i wanna keep the Container-managed infrastructure and just change some values at runtime

is there any way to do this with SessionContext or anything else ?

what is the best way of overcoming this issue ?

thanks in advance

Upvotes: 0

Views: 506

Answers (1)

A.H.
A.H.

Reputation: 66263

@PostConstruct is by definition the wrong way, because it is only a hint to the bean that it has been constructed and its dependencies have been injected. The bean is now in the pool of EJBs waiting for the first service call. Then it will be connected to the client info of that call. After that call the client info is disconnected again.

I think any kind of standard injection and standard container managed persistence stuff will not work in your case because injection is done exactly once (at EJB creation time) but your case would require injection for each service call/transaction _AND your injection would depend on input data - the client request containing the tenant id.

Also: I hope, you have only up to 6 (or so) tenants due to the maintenance and performance burden of that approach. I have never seen this approach working in the wild.

Upvotes: 1

Related Questions