OFBiz
  1. OFBiz
  2. OFBIZ-2020

Using one Ofbiz instance with multiple databases

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: Trunk
    • Fix Version/s: Trunk
    • Component/s: None
    • Labels:
      None

      Description

      I want to share my work with you implementing the use of one OFBiz instance with multiple databases, by defining multiple delegators, in the entityengine.xml, one for each databases. this is useful when we implementing ofbiz for semi-independent subsidiaries of one company having users allowed to use two or more databases.
      This involve mainly the user authentication procedure by asking for a company name in the login form. This company name represents a delegator name that describe a specific subsidiary database. After a successful user login operation, the passed company name is used to retrieve the corresponding delegator. The method CoreEvents.chageDelegator is modified to change the delegator of related Dispatcher and JobManager.
      Of course I needed to store the delegator name in the GenericValue UserLogin to navigate among different ofbiz applications keeping the same original database.
      I also provided a kind of mechanism to activate or deactivates the use of multi-delegator by adding a "multi.delegator" property in the security.properties configuration file that when set true, cause the ofbiz to display he company field in the login form and do the necessary work to switch from default database to the provided one.
      I will be open to discuss any suggestion for improving this issue.
      Following is a patch for current ofbiz trunk version:

      1. ofbiz-multi.patch
        27 kB
        youssef khaye
      2. entitymodel.xml.rej
        0.5 kB
        Jacques Le Roux
      3. ofbiz-multi.patch
        24 kB
        Jacques Le Roux
      4. ofbiz-multi.patch
        28 kB
        youssef khaye

        Activity

        Hide
        BJ Freeman added a comment -

        can you give a overview for this requirement.
        I am interested in how entity-views across applications, therefor delegators are handled.
        how do you deal with the sandbox?
        also why not entity-sync.

        Show
        BJ Freeman added a comment - can you give a overview for this requirement. I am interested in how entity-views across applications, therefor delegators are handled. how do you deal with the sandbox? also why not entity-sync.
        Hide
        youssef khaye added a comment -

        Thank you Freeman for the comment;
        I really dont understand wha do you means by entity-views across applications, but for sandbox i just switch the database of the JobManager to database of the user by changing the JobManager.delegator.

        Show
        youssef khaye added a comment - Thank you Freeman for the comment; I really dont understand wha do you means by entity-views across applications, but for sandbox i just switch the database of the JobManager to database of the user by changing the JobManager.delegator.
        Hide
        Jacques Le Roux added a comment -

        Hi Youssef,

        Please use relative pathes for your patches (read carefully http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices)

        Anyway after removing your specific path, I got this error.

        D:\Workspace\ofbizRun>patch -p0  0<ofbiz-multi.patch
        patching file applications/party/entitydef/entitymodel.xml
        Hunk #1 succeeded at 2615 (offset 4 lines).
        patching file framework/common/config/CommonUiLabels.xml
        patch: **** malformed patch at line 31: Index: framework/common/src/org/ofbiz/common/login/LoginServices.java
        

        Then I tried with Eclipse (using Subclipse "Apply patch" option) and was able to apply the modified patch (see patch attached) but an hunk in entitymodel.xml. See entitymodel.xml.rej, I guess you need to put your comments at end of lines instead between but I can't see why and not sure though since I gave up at this stage

        Show
        Jacques Le Roux added a comment - Hi Youssef, Please use relative pathes for your patches (read carefully http://docs.ofbiz.org/display/OFBADMIN/OFBiz+Contributors+Best+Practices ) Anyway after removing your specific path, I got this error. D:\Workspace\ofbizRun>patch -p0 0<ofbiz-multi.patch patching file applications/party/entitydef/entitymodel.xml Hunk #1 succeeded at 2615 (offset 4 lines). patching file framework/common/config/CommonUiLabels.xml patch: **** malformed patch at line 31: Index: framework/common/src/org/ofbiz/common/login/LoginServices.java Then I tried with Eclipse (using Subclipse "Apply patch" option) and was able to apply the modified patch (see patch attached) but an hunk in entitymodel.xml. See entitymodel.xml.rej, I guess you need to put your comments at end of lines instead between but I can't see why and not sure though since I gave up at this stage
        Hide
        youssef khaye added a comment -

        Hi Jacques,
        It was a great pleasure to read from you. For the relative path issue I did the nessecery.
        My old patch was made from the 705872, revesion and i was surprised when you told that didn't work.
        I make a newer patch on the old revision 705872, then I updated my project before doing the eclipse create patch.
        To be sure that will work, I applied the patch on the base version and still working.
        Best regards.

        Show
        youssef khaye added a comment - Hi Jacques, It was a great pleasure to read from you. For the relative path issue I did the nessecery. My old patch was made from the 705872, revesion and i was surprised when you told that didn't work. I make a newer patch on the old revision 705872, then I updated my project before doing the eclipse create patch. To be sure that will work, I applied the patch on the base version and still working. Best regards.
        Hide
        youssef khaye added a comment -

        Hi jacques again,
        For relative path, using eclipse, you can check "ignore leading path name segment" to overcome the issue.
        Best regards.

        Show
        youssef khaye added a comment - Hi jacques again, For relative path, using eclipse, you can check "ignore leading path name segment" to overcome the issue. Best regards.
        Hide
        Jacques Le Roux added a comment -

        Thanks Youssef,

        Yes I know for Eclipse, actually most of the time I use Tortoise (on Windows) and it takes care of path issues automatically. But in your case it did not, I guess because your patch was not done on Windows. Anyway this was not a big worry, it's only because it's simpler for commiters which are not all using Eclipse.

        I just tried to apply your patch, it's ok now. I will try to review and test this week, not sure though...

        Show
        Jacques Le Roux added a comment - Thanks Youssef, Yes I know for Eclipse, actually most of the time I use Tortoise (on Windows) and it takes care of path issues automatically. But in your case it did not, I guess because your patch was not done on Windows. Anyway this was not a big worry, it's only because it's simpler for commiters which are not all using Eclipse. I just tried to apply your patch, it's ok now. I will try to review and test this week, not sure though...
        Hide
        David E. Jones added a comment -

        This patch must not be committed as-is. It appears to not be thread safe. In general a dispatcher should not have the delegator changed on the fly, there may be too much depending on the previous delegator (database set). It is also not thread-safe, or in other words one user changing the delegator would affect other users using the same dispatcher.

        Show
        David E. Jones added a comment - This patch must not be committed as-is. It appears to not be thread safe. In general a dispatcher should not have the delegator changed on the fly, there may be too much depending on the previous delegator (database set). It is also not thread-safe, or in other words one user changing the delegator would affect other users using the same dispatcher.
        Hide
        Jacques Le Roux added a comment -

        Also Youssef,

        If ever you change for a thread-safe patch, be carefull about labels files. In framework/webapp/config/WebappUiLabels.xml

        You put
        <value xml:lang="fr">Merci de v\u00E9rifiez l'entrepripse</value>
        it should be
        <value xml:lang="fr">Merci de vérifier l'entreprise</value>

        also use only the default when there are no translation for other languages
        so
        <value xml:lang="en">Company not found, please re-enter.</value>
        only

        Show
        Jacques Le Roux added a comment - Also Youssef, If ever you change for a thread-safe patch, be carefull about labels files. In framework/webapp/config/WebappUiLabels.xml You put <value xml:lang="fr">Merci de v\u00E9rifiez l'entrepripse</value> it should be <value xml:lang="fr">Merci de vérifier l'entreprise</value> also use only the default when there are no translation for other languages so <value xml:lang="en">Company not found, please re-enter.</value> only
        Hide
        youssef khaye added a comment -

        Hi Mr Jones;
        Thanks for your interesting.
        Reading your comment makes me think of the matter, It seems to be more significant to create a dispatcher in the same time with a delegator if someone request a connection for a database without them already created, and why not a new jobmanager too.
        This would solve the issue because every dispatcher with its own (jobManager,delegator) will continue working with their DB.
        Since the issue of multi delegator can be very useful in a production environment, I will be volunteer to accomplish the necessary work, of course with the guidance of persons like you and Mr Le Roux.
        Best regards.

        Show
        youssef khaye added a comment - Hi Mr Jones; Thanks for your interesting. Reading your comment makes me think of the matter, It seems to be more significant to create a dispatcher in the same time with a delegator if someone request a connection for a database without them already created, and why not a new jobmanager too. This would solve the issue because every dispatcher with its own (jobManager,delegator) will continue working with their DB. Since the issue of multi delegator can be very useful in a production environment, I will be volunteer to accomplish the necessary work, of course with the guidance of persons like you and Mr Le Roux. Best regards.
        Hide
        Jacques Le Roux added a comment -

        Any news Youssef ?

        Show
        Jacques Le Roux added a comment - Any news Youssef ?
        Hide
        youssef khaye added a comment -

        The main problème i get now is when changing the delegator on userLogin event, all already existing users get their work done on the new database but not the one they requested. In Other words, i thought that a session is created for each user, so that i put the delegator and dispatcher info in the session, meanwhile, this make those delegator and dispatcher available for everybody.
        Exemple: i used two users
        admin : connects to database delegator
        flexadmin: connects to databse company1
        -admin connect and plan a job( serviceName: myService ) that append the userLoginId & delegator (both giot from dispatchContext) in a file.
        -now flexadmin connect and plan an other job (serviceName: myOtherService) that append the same info to the same file.
        I expected that my file will contain the loginId and delegator name for both user in an alternative way. But in my file i have only the flexadmin userloginId and delegator (he loged in after the admin). which means that the last user who logged in changes the delegator for all existing users.

        Show
        youssef khaye added a comment - The main problème i get now is when changing the delegator on userLogin event, all already existing users get their work done on the new database but not the one they requested. In Other words, i thought that a session is created for each user, so that i put the delegator and dispatcher info in the session, meanwhile, this make those delegator and dispatcher available for everybody. Exemple: i used two users admin : connects to database delegator flexadmin: connects to databse company1 -admin connect and plan a job( serviceName: myService ) that append the userLoginId & delegator (both giot from dispatchContext) in a file. -now flexadmin connect and plan an other job (serviceName: myOtherService) that append the same info to the same file. I expected that my file will contain the loginId and delegator name for both user in an alternative way. But in my file i have only the flexadmin userloginId and delegator (he loged in after the admin). which means that the last user who logged in changes the delegator for all existing users.
        Hide
        Bruno Busco added a comment -

        I think you should find interesting the work David has done and committed here:
        ofbiz/branches/multitenant20100310

        Show
        Bruno Busco added a comment - I think you should find interesting the work David has done and committed here: ofbiz/branches/multitenant20100310
        Hide
        Erwan de FERRIERES added a comment -

        A different implementation has been chosen with multitenant

        Show
        Erwan de FERRIERES added a comment - A different implementation has been chosen with multitenant

          People

          • Assignee:
            Unassigned
            Reporter:
            youssef khaye
          • Votes:
            4 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development