geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Multiple Instances With One Repository
Date Fri, 17 Oct 2008 17:15:29 GMT

On Oct 17, 2008, at 7:02 AM, randersen wrote:

>
>
>
> djencks wrote:
>>
>>
>> On Oct 16, 2008, at 11:56 AM, randersen wrote:
>>
>>> The structure would be more like:
>>>
>>> GERONIMO_HOME
>>>   customers
>>>       customer1
>>>           customer1-repo
>>>           instance1
>>>               var
>>>           instance2
>>>               var
>>>       customer2
>>>           customer2-repo
>>>           instance1
>>>             var
>>>
>>> This would allow the deployment of multiple customers on 1 machine
>>> that use
>>> different databases to use the same database pool without having to
>>> deploy a
>>> second repository in each instance for the database pool.  Is there
>>> a system
>>> property for the repository directory like there is for the var
>>> directory?
>>
>> I'd like to know more about what you are trying to do.  If each
>> customer is using the same applications and the only difference
>> between them is which database their copy of the app needs to connect
>> to then you only need one repo.  The only reason I can think of to
>> have one repo for each customer is if you have apps for one customer
>> that you need to prevent being started on other customer's servers.
>>
>> In the unlikely event you are using derby or another db that stores
>> data inside geronimo's var dir then each customer will already get a
>> new copy of derby simply because they have their own var dir.
>>
>> In the more likely event you are using an external db and each
>> customer has their own copy you have at least these two options:
>>
>> 1. use a config.xml snippet with a config-substitutions variable for
>> the db name or url (and user/pw presumably) and set these in each
>> server's var/config/config-substitutions.properties
>>
>> 2. deploy a fully configured db pool on each customer's server
>> pointing to the appropriate db and use artifact-aliases to have it
>> replace a standard or dummy db pool.
>>
>> still trying to understand what you are trying to do....
>> thanks
>> david jencks
>>
>> The only difference is the database to which they are connecting to  
>> and it
>> is an external one. We will be running multiple customers (each  
>> customer
>> having a different database connection) with multiple instances for  
>> that
>> customer on the same host and using the same version of the  
>> application.
>> The only thing that needs to change is the db connection  
>> information for
>> the database pool.
>>
>> 1. Would that be this line:
>>    <module name="console.dbpool/CustomerDBPool/1.0/rar"/>
>>
>>   how do you specify the attributes for it?
>>
>> 2. I don't understand this part, are you saying that for each  
>> customer we
>> have a separate installation of geronimo?  So if I have 3 customers  
>> on one
>> host I'll have 3 installed versions of the software with the instance
>> config under each one?
>>
>> I like the sound of #1, that would mean that we could have 1  
>> installation
>> of geronimo and have all the instances underneath and just change
>> config.xml for the ones that would use a different db connection.
>>
>>

Both solutions involve only one installation of geronimo.  Both  
involve deploying the datasource as a geronimo plugin and using some  
plugin features.  If you have any maven familiarity at all it's  
easiest to generate the plugins using maven and the car-maven-plugin,  
although it's not essential.  In either case I'd generate the initial  
plan for the datasource using the admin console.

There are some general instructions on setting up maven plugin  
projects here: http://cwiki.apache.org/GMOxDOC22/constructing-a-special-purpose-server-using-maven.html

in either case you'd create the multiple geronimo instances with  
something like

mkdir -p customer1/instance1
cp -r var customer1/instance1
... repeat for all customers, instances

for (1) you probably want to do this after deploying the app and  
datasource plugin and for (2) before deploying the app and datasource  
plugin.

(1).  You'll need the full abstract name of the  
JCAManagedConnectionFactoryWrapper that represents the datasource.  I  
think you can determine it by turning logging to debug and starting  
the server after the datasource is installed.  Look at the log..... it  
may take some searching.

in the car-maven-plugin configuration in the pom.xml set up a  
config.xml snippet like....

                     <instance>
                         <plugin-artifact>
                             <config-xml-content>
                                 <gbean name="---(name of  
JCAManagedConnectionFactoryWrapper)---">
                                     <attribute name="Database">$ 
{DBName}</attribute>
                                 </gbean>
                            </config-xml-content>
                             <config-substitution  
key="DBName">Customer1DB</config-substitution>
                         </plugin-artifact>
                     </instance>

The actual attribute(s) you use will depend on which tranql wrapper  
you are using: any config-property name can be used as an attribute.   
What this does is expose these attributes as properties in var/config/ 
config-substitutions.properties.  After you copy the var directory  
into the multiple locations you can edit each customer${x}/instance$ 
[y}/var/config/config-substitutions.properties to have the correct  
value for that instance.

(2)  Create a datasource plugin for each customer db, set up to  
connect to that db.  Instead of modifying the config-xml-content and  
using a substitution variable you'll have each plugin replace a  
default one.  For the non-default datasources include something like
                     <instance>
                         <plugin-artifact>
                             <artifact-alias key="org.myco/ 
defaultDatasource//car">org.myco/datasourceX/${version}/car</artifact- 
alias>
                             <artifact-alias key="org.myco/ 
defaultDatasource/${version}/car">oorg.myco/datasourceX/${version}/ 
car</artifact-alias>
                         </plugin-artifact>
                     </instance>

set up all the instances and deploy the appropriate datasource and the  
app on each of them.  The code will only get installed once into the  
single repository but each installation will be using the datasource  
you deployed on it.  It might seem a bit mysterious but the individual  
var/config/config.xml files control which plugins are started on each  
server instance so by deploying the appropriate datasource plugin on  
each server instance only that datasource will be started.

Hope this helps.... seems like a good topic for a help page, perhaps  
I'll be able to scrape together more time to set up an example.

thanks
david jencks


>
> -- 
> View this message in context: http://www.nabble.com/Multiple-Instances-With-One-Repository-tp20001882s134p20033920.html
> Sent from the Apache Geronimo - Dev mailing list archive at  
> Nabble.com.
>


Mime
View raw message