When the OM generates business object classes, it "stamps" them with the DataSourceKeyName specified in the Object Mapper. (It's the value in the "Key" column in the "Data Source Keys" grid.)  Since your DBa and DBb databases have the same structure, you could use either of them for your design-time work.  So, in the Object Mapper, you would add a second row to the Data Source Keys grid.  You would point the first row to database DB1, and the second to DBa (or DBb, or any other database with the same structure).  

When you instantiate a PersistenceManager (to retrieve and save objects), you can specify a DataSourceExtension (string).  (If you don't specify one, it gets an extension consisting of an empty string.) Then when you ask that PM to retrieve some objects, it finds or creates a DataSourceKey (in memory) object based upon (1) the DataSourceKeyName embedded in the class for the objects of the type to be retrieved, and (2) the DataSourceExtension associated with the PersistenceManager.  A DataSourceKeyResolver uses a method, GetKey(KeyName, KeyExtension) to find or create this DataSourceKey object. The object includes the connection string necessary to access a specify physical instance of the database.

For the purpose of discussion, let's say that, in the Data Source Keys grid in the Object Mapper, you leave the name of the key in the DB1 record as "default", but rename the one in the second row from "Key" to "secondary".  Then in your code you instantiate a PersistenceManager using a overload of the PersistenceManager's constructor that let's you specify the extension, and that you specify an extension of "B".  Then, when attempting to retrieve objects from your first database, your app would look for a key with a name of "default" and an extension of "".  When attempting to retrieve objects from your second database, your app would look for a key with a name of "secondary" and an extension of "B".  In either case, the first request for data from the the first database would result in the creation of one in-memory DataSourceKey object; and the first request for data from the secondary database would result in the creation of a second (and different) in-memory DataSourceKey object. Subsequent requests for data from either database would NOT result in the creation of any more DataSourceKeys; rather, the existing ones would be found and used.

You actually do not necessary need a custom DataSourceKeyResolver to make this work. If your ibconfig file has proper entries, the default resolver will find the right copy of the second database.  The section of your ibconfig file containing RdbKeys, for example, might look like the following:

  <rdbKey name="default" databaseProduct="Unknown">
    <connection>Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=Xyz;Data Source=.</connection>
    <probeAssemblyName>Model</probeAssemblyName>
  </rdbKey>

  <rdbKey name="secondary_A" databaseProduct="Unknown">
    <connection>Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=Pdq;Data Source=.</connection>
    <probeAssemblyName>Model</probeAssemblyName>
  </rdbKey>

  <rdbKey name="secondary_B" databaseProduct="Unknown">
    <connection>Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=Abc;Data Source=.</connection>
    <probeAssemblyName>Model</probeAssemblyName>
  </rdbKey>

The default DataSourceKeyResolver would find the rdbKey entry corresponding to the needed DataSourceKey by concatenating the DataSourceKeyName (obtained from the business object type) and the DataSourceExtension (obtained from the PersistenceManager) and comparing the result to the name specified in the rdbKey.  Thus, if your app had instantiated the PM as follows:

    ...

    datasourceExtensionName = "B";

    PersistenceManager pm =  new PersistenceManager (true, datasourceExtensionName);

    ...

then, while attempting the first retrieval of objects of a type sourced in the secondary database, it would create a DataSourceKey using information mined out of the third rdbKey entry above.  It would therefore access the database named "Abc".  Any subsequent request to access data in the same database would use the in-memory DataSourceKey object created for this first access; that is, DevForce would not go back to the ibconfig file. 

The best source of further information about this is probably the section "DevForce and Data Sources – Digging Deeper", in Chapter 4 of the IdeaBlade DevForce Developers Guide. 

I start a new project right after the training on your side. My project involves in multiple databases at run time. 

The case is:

I have databases as DB1, DBa, DBb. DB1 has different structure from DBa and DBb, and DBa and DBb have the same structure.

My application will need to connect to DB1 and either DBa or DBb at every runtime base on the database name I pass in dynamically. I follow the training material to write my own custom DataSourceKeyResolvers and add it to the AppHelp project to have the PM point to a desired Datasource. 

My question is how should I use the object mapper to generate the business objects for DB1 and DBa(b)?

Do you have a complete example to show more detail of implement the Custom DatasourceKeyresolvers ?  

Or do you have a better approach to handler this case?