Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Each client with one database schema + JPA. How to implement it ?  RSS feed

 
Pedro Lobato Sena
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Guys,

We are migrating a system that has a database schema for each client(we have 100 clients, more or less). All the schemas have the same tables.

We will use Seam + EJB3 + JPA.

I would like to know what is the best approach to design a part of my persistence layer: the management of entityManagers.

I had an idea, but I don't know if it is possible:

Create a SFSB that contains the EntityManager that I need for that specific client(that should occurs when the client makes the login).

Then access this specific SFSB in all subsequent Session Beans that the client may call, being they Stateful or Stateless.

Now my big question:

Is it possible to make sure that my 'secondaries' session beans calls exactly the SFSB that has the specific entityManager that I need ? If yes, how ?

Thanks for your time,

Pedro Sena
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pedro,

I would honestly re-think your database design. You are likely to be much better off storing data for all clients in a single schema if that's an option for you. Managing 100+ schemas is likely to be a maintenance hazard (propagating changes, synchronization, tuning, monitoring, backup) for the DB team in any non-trivial production environment!

That being said, if you have to dynamically switch entity managers at run-time, you really can't rely on injection too much. Here is what you will need to do:

1. Save the client name in the HTTP session space somewhere.
2. Pass in the client name for each request to an EJB as a parameter.
3. As an alternative to the above, you can use stateful session beans placed in the Seam "session" context and inject them using @In from the session context as needed. You'll still need to pass in the client name somehow at least when the bean is first created.
4. Dynamically create an entity manager using an entity manager factory and the persistence unit name that maps to a client. Such entity managers will automatically participate in EJB transactions even if they are not injected.

IMO, all this really isn't worth the effort unless clients are mandating separate schemas. In the worst case, these mechanisms will likely cause chronic performance problems due to strain on the memory space/database resources. Lastly, simply having client specific web applications might make things easier from a development perspective...

Regards,
Reza
[ November 21, 2008: Message edited by: Reza Rahman ]
 
Pedro Lobato Sena
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Reza,

First of all, thank for your reply.

This database architecture if from a legacy system, that we can't change right now.

We have some clients that just bought our product because we have this kind of infrastructury, I do not full agree with them, but I undertand.

About the management of those entityManagers, is it possible to do what I described in the first post?

I was thinking:

1) When the client logins, create a SFSB with the correct entityManager for this client.
2) When the client call another service(another EJB, stateful or not) this other EJB will take the correct entityManager from the SFSB(is it possible?How?) and then make what is necessary.

For me, appears to be a good approach, I know it can be not the better, but would solve my actual problem.

What do you think about it? Is it possbible?

Thanks for your time
[ November 21, 2008: Message edited by: Pedro Lobato Sena ]
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pedro,

Sorry to hear about the legacy design headache...

What you are saying is possible in theory. Without using Seam, you would have to store the SFSB instance reference in the HTTP session and pass it around as needed - pretty painful and error-prone. The other approach as I mentioned, is to store a SFSB instance in the Seam session context and inject it from there as needed.

Regards,
Reza
 
Pedro Lobato Sena
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Reza,

I was thinking that, instead of storing the entite SFSB, it's better to store just the correct entityManager in Seam, isn't it?

Another question that I have:

Using this approach won't I loose the container management(specially with transaction) of my entity manager ?

Thanks again,

Pedro Sena

PS: I bought your book but amazon is taking to much time to deliver it here in brazil(more than a month), hope your book can help me too
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pedro,

Yes, storing the entity manager in the session context could work too. Haven't done it myself though, so can't comment on it.

A dynamically created entity manager will still participate in a JTA transaction when it is present. However, this is also something I haven't tried myself. You have to do manual flushes in the worst case scenario.

Regards,
Reza

P.S.: Hope you enjoy the book. Let me know if you have any feedback, since we're planning the second edition right now, it will really help.
 
Pedro Lobato Sena
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Reza,

I will make a couple of test and as soon as I get a result I'll post it there.

Thanks for yours replys, they were very helpful.

Regards,

Pedro Sena
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!