13 Replies Latest reply on Apr 1, 2008 3:29 PM by renton1982

    User Specific EntityManager (DB)

    jbossindia

      I have a requirement where mutliple db (same schema) will be used in an application.


      I want to inject EntityManager based on the user.


      How can I achieve this.

        • 1. Re: User Specific EntityManager (DB)
          renton1982

          i would be interessted in this issue too...

          • 2. Re: User Specific EntityManager (DB)
            renton1982

            hmm just an idea (not tested)


            try to devine several EntityManagers with differnt (user)names


            in your source: inject your EntityManger with the name of your user...


            eg:


            @In
            private EntityManager user1;


            • 3. Re: User Specific EntityManager (DB)
              stephen

              This is a feature that is completely straightforward when using JDBC manually, but is amazingly difficult when using JPA.


              Over the years that I am using Hibernate this came up time and again.
              Occasionally somebody reported a working solution, but AFAIK nothing comprehensive was ever posted.


              For example see 
              this discussion
              at the JBoss forum and also search the hibernate forum.

              • 4. Re: User Specific EntityManager (DB)

                Searching this forum gives:
                http://www.seamframework.org/Community/MultiplePersistenceManagers


                You could try something like this (totally just out of my head)



                     <persistence:managed-persistence-context name="em1" auto-create="true" entity-manager-factory="#{em1Factory}" />
                     <persistence:entity-manager-factory name="em1EntityMgrFact" persistence-unit-name="em1punit" />
                
                     <persistence:managed-persistence-context name="em2" auto-create="true" entity-manager-factory="#{em2Factory}" />
                     <persistence:entity-manager-factory name="em2EntityMgrFact" persistence-unit-name="em2punit" />
                



                And then


                @Name("emFactory")
                public class EmFactory {
                   @In EntityManager em1;
                   @In EntityManager em2;
                   @In User user;
                
                   public EntityManager getEm() {
                      if(user.is.someone) return em1;
                      if(user.is.someoneelse) return em2;
                   }
                }
                
                



                public class SomeAction {
                   @In EmFactory emFactory;
                
                   public saveSomeThing() {
                      emFactory.getEm().persist(thing);
                   }
                }
                
                


                • 5. Re: User Specific EntityManager (DB)
                  cpopetz

                  Well...why?


                  I can completely understand:


                  @In EntityManager mainEM;
                  @In EntityManager loggingEM;
                  @In EntityManager accountingEM;
                  



                  and that's easy enough to do.  But what's the use case for needing a different EM for each user, or dynamically selecting an EM based on the user?  The only use-case I can think of is for horizontal partitioning of data, but in that case, why not just use shards?

                  • 6. Re: User Specific EntityManager (DB)
                    renton1982

                    just for example: you have ONE software running on your server and several customers of you using this one instance of your app (more easy to maintain, new customer is just a new login,...)


                    so you need several datasources to guarantee, that every of your customers must use his own database

                    • 7. Re: User Specific EntityManager (DB)
                      renton1982

                      hmm this looks like a great idea for a workaround, but dont i poll the server to much if i create so much em-instances on every db-connect?

                      • 8. Re: User Specific EntityManager (DB)
                        christian.bauer

                        The correct solution is to write a custom Hibernate ConnectionProvider that obtains the right database connection for the same EntityManager. I'm sure there is a wiki page about it somewhere. Do not enable the second-level Hibernate cache then!

                        • 9. Re: User Specific EntityManager (DB)
                          cpopetz

                          Ok, devil's advocate...why would each customer need their own database?  That's certainly not how must online multi-user apps strategize their data partioning.  I suppose you get the advantage of ensuring that one user can never touch another user's data, but that's a pretty heavy-handed way of doing that.


                          • 11. Re: User Specific EntityManager (DB)
                            christian.bauer

                            Usually there are no technical reasons for doing this, it's just how it is sold to technically challenged customers, as a security feature. It seems to be pretty popular in German speaking European countries though (the original poster is from Austria).

                            • 12. Re: User Specific EntityManager (DB)
                              jbossindia

                              Hi,


                              thanks all for your replies.


                              The requirement is for SaaS based model 3 which stipulates the use of different schemas for different customers in SaaS offering.


                              In this case all app instances will be clustered and will connect to correct DB after the user is authenticated.

                              • 13. Re: User Specific EntityManager (DB)
                                renton1982

                                Hi!


                                In fact there are technical AND security reasons. If you develop SaaS Software, not every customer has the same requirements in ressources. Some of them grow fast, some not. So if one of your costumer needs his own server, you can just place the database onto better hardware.


                                The second case is: if your contract will end, you have to hand over all of your customers data. Its much more easier to just make a dump of your database then seperating all of the needed from the not needed data by hand...


                                Or for example one of your customers want to use its own hardware at his office, how do you move his data to the new location when its mixed up with the data of your other customers.


                                Its just much more scalable then putting all the data in one hardware...


                                @ Christian: thanks for the Link to Hibernate!


                                greetings


                                Berni