I think JobPoller has no preffered db set up inside, so it obviously has a
problem which resource should be used in particular job. Do you have a
relationship between job and session? Or it's not about jobs in separated
threads?

It's seems like if you disable a job pool and use only session per
delegator/dispatcher pair (usual servlet request/response interface) this
approach works.

Any suggestions?


JIRA [email protected] wrote:
> 
> 
>     [
> https://issues.apache.org/jira/browse/OFBIZ-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12672986#action_12672986
> ] 
> 
> youssef khaye commented on OFBIZ-2020:
> --------------------------------------
> 
> 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.
> 
> 
>> Using one Ofbiz instance with multiple databases
>> ------------------------------------------------
>>
>>                 Key: OFBIZ-2020
>>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2020
>>             Project: OFBiz
>>          Issue Type: New Feature
>>    Affects Versions: SVN trunk
>>            Reporter: youssef khaye
>>             Fix For: SVN trunk
>>
>>         Attachments: entitymodel.xml.rej, ofbiz-multi.patch,
>> ofbiz-multi.patch, ofbiz-multi.patch
>>
>>
>> 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:
> 
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/-jira--Created%3A-%28OFBIZ-2020%29-Using-on-Ofbiz-instance-with-multiple-databases-tp20163969p22049209.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Reply via email to