Proactive insights, news and tips from Oracle WebLogic Server Support. Learn Oracle from Oracle.

  • December 8, 2015

Multi-Tenancy Samples

In order to make it easier to understand all aspects of Multi-tenancy in
WebLogic Server 12.2.1.*, MedRec can support running in a Multi-tenancy
environment to be used as a demonstration vehicle.

What’s MedRec

Medical Records (or MedRec) is a WebLogic Server sample application
suite that demonstrates all aspects of the Java Platform, Enterprise
Edition (Java EE). MedRec is designed as an educational tool for all
levels of Java EE developers. It showcases the use of each Java EE
component, and illustrates best-practice design patterns for component
interaction and client development. MedRec also illustrates best
practices for developing and deploying applications with WebLogic

Please choose 'Complete with Examples' when you install WebLogic
server whilst going to the step of 'Installation Type'. The codes,
binaries and documentations of MedRec will be located at
‘$MW_HOME/wlserver/samples/server/medrec’ directory. Otherwise samples
of WebLogic Server will be overleaped.

There are two non-OOTB Multi-tenancy samples. You need to run Ant commands provided to stage WebLogic domains.

Single Server Multi-tenancy MedRec


a SAAS sample that is all focusing on the Multi-tenancy features
themselves, without cluster, extra managed servers, all virtual targets
only target to admin server.

Multi-tenancy Demonstration

are 2 tenants named bayland and valley, and valley has 2 partitions(one
tenant can have multiple partitions). In this sample, it’s
demonstrating various Multi-tenancy features following. If you have any
questions about a certain feature, you'd refer to the relevant blogs or

Resource Group Template

resources including applications, JMS, file store, mail session, JDBC
system resource are deployed onto a resource group template.

  • Applications

  • Other resources

Resource Overriding

are supposed to be isolated among partitions. At resource group
template, the JDBC system resource is a mere template with name, driver,
JNDI lookup name. The real URL, username, password of datasource are
set at the resource overriding in Partition scope.

Virtual Target

partition, exactly each partition resource group deriving from
forementioned MedRec resource group template has it own virtual target.
The 2 virtual target of valley share the same host names within
different URI prefixes.

can see three virtual targets, one per one partition. Web container is
aware of which application is accessed to according to the host name
plus URI prefix. For example, in this sample, medrec.ear is deployed at
all partitions. Yet how to access the web module of medrec.ear on
bayland? The URL would be 'http://hostname:port/bayland/medrec'.
'/bayland' is the uri prefix. 'medrec' is the root context name of

Security Realm

tenant is supposed to have its own security realm with isolated users.
MedRec has an use case of Servlet access control and authentication that
demonstrates the scenario.

Resource Consumption Management.

Bayland is deemed as a VIP customer of this sample. So it has more quota of CPU, memory heap, thread work, etc.

Trigger will slow down or shut down the partition if the usage is up to the specified value.

Partition Work Manager

Work Managers define a set of policies that limit the usage of threads
by Work Managers in partitions only. They do not apply to the domain.

Deployment Plan

deployment plan file can be used in partition scope. The sample
utilises this mechanism to change the appearance of the web pages on
valley tenant including photos and background colour. That means you can
let your application different from each other of different partition
even though of one resource group template.


to running setup script, you need to do a couple of preparation.
Setting sample environment, editing etc/hosts file, customising the
properties of admin server, host, port etc. After that, one ant command
will stage all content of the SAAS sample.

  1. Setting environment.

    cd $MW_HOME/wlserver/samples/server
    . ./setExamplesEnv.sh
  1. Network address mapping. Please open /etc/hosts file and add following lines: www.baylandurgentcare.com www.valleyhealth.com
  2. Customizing admin server properties.
    update 5 properties in $MW_HOME/wlserver/samples/server/medrec/install/mt-single-server/weblogic.properties. Please use weblogic as the username of the admin server.

  3. Running setup script

    cd $MW_HOME/wlserver/samples/server/medrec
    ant mt.single.server.sample

Webapp URLs

You can access MedRec via following URLs according to the server port you set. For example, you set admin.server.port
= 7005

Coherence Cluster Multi-tenancy MedRec


second SAAS sample. Beyond the simple one, coherence cache, dynamic
cluster, Oracle PDB are involved. In some extent, it’s a real usage of
MT in practice.

at this diagram above, it also has 2 tenants but a partition per
tenant. Bayland is the blue one, valley the green one. There are 2
resource group templates named app RGT and cache RGT instead of one. App
RGT is similar to the resource group template of the first MT sample
including all resources of MedRec. In order to enable coherence cache, a
GAR archive is packaged into an application of medrec.ear. And the
identical GAR is also deployed into the second cache resource group
template. Both of the partitions have 2 resource groups app and cache
deriving from the app and cache resource group templates respectively.
Each resource group targets to different virtual target. So here has 4
virtual targets. 2 app virtual targets target to a storage disabled
dynamic cluster app cluster with 2 managed servers. The applications
and other resources run on this app cluster. In contrast, 2 cache
virtual targets target to another dynamic cluster named cache cluster
with 2 managed servers but storage enable. The GAR of cache resource group runs on the cache cluster.

Coherence Scenario

has 2 key archives medrec.ear and physician.ear. Physician archive is
set to a web service(JAX-RS and JAX-WS) client application. And there
aren't any JPA stuff in physician.ear all of which are in server side. 
So leveraging Coherence Cache here can avoid frequent web service
invocations and JDBC invocations in business services of web service
server side.

Method Invocation Cache

cache is one partitioned tenant cache. Most of business services of
physician scenarios are annotated method invocation cache interceptor.
First check data whether it has stored in cache. If data isn't cached,
gets data through web service. Then stores return data into method
cache. After that, following invocations with same values of parameter
will fetch data from cache directly.

When is the data removed from
the method cache? For examples, physician can look a patient's record
summary which is cached after first getting the data. And physician
creates a new record for this patient. At present, the record summary in
the cache has already been inaccurate. So the dirty data should be
cleaned. In this case, after success of creating record, the business
service will fire an update event to remove the old data.

Method invocation cache has 3 different types. MedRec can be aware of
the WLS environment and activate the relevant cache.

For example,
physician login, when you first login as physician at bayland app server
1, the app_cluster-1.log should be printed liking following logs:

Method Invocation Coherence Cache is available.
Checking method XXXX invocation cache...
Not find the result.
Caching the result in method XXXX invocation cache....
Added result to cache
Method: XXXXX
Parameters: XXXX
Result: XXXXX

Logout and change to bayland server 2 login again, the app_cluster-2.log should like these:

Checking method XXXX invocation cache...
Found result in cache
Method: XXXXX
Parameters: XXXX
Result: XXXXX

Shared Cache

cache is one partitioned shared cache that means bayland and valley can
share it. It's still the creating record user-case. Physician can
create prescriptions for the new record. Choosing drug uses a drug
information list from database of server side. The list is a stable
invariable data so that can be shared with both Partitions. So the drug
information list is stored in this cache.

Open creating record page on browser at bayland server 1, the app_cluster-1.log should like this:

Drug info list is not stored in shared cache.
Fetch list from server end point.
Store drug info list into shared cache.

Then do the same thing at valley server 2, the app_cluster-2.log should like this:

Drug info list has already stored in shared cache.

That means the it is a shared cache over Partitions.


installation and usage are similar to the first MT sample. Beyond the
first one, the first sample adopts derby as database, the second adopts
Oracle database. You need to prepare 2 Oracle PDBs and customize the
file of db properties.

  1. Setting environment.

    cd $MW_HOME/wlserver/samples/server
    . ./setExamplesEnv.sh
  2. Update 5 properties in
    according with PDBs. E.g.:

    # Partition 1
    dbURL1      = jdbc:oracle:thin:XXXXXXXX:1521/pdb1
    dbUser1     = pdb1
    dbPassword1 = XXXXXX
    # Partition 2
    dbURL2      = jdbc:oracle:thin:XXXXXXXX:1521/pdb2
    dbUser2     = pdb2
    dbPassword2 = XXXXXX
  3. Network address mapping. Please open /etc/hosts file and add following lines: bayland.weblogicmt.com valley.weblogicmt.com
  4. Customizing admin server properties.
    update 5 properties in $MW_HOME/wlserver/samples/server/medrec/install/mt-coherence-cluster/weblogic.properties. Please use weblogic as the username of admin server.

    admin.server.port=7003 (Please don’t use 2105, 7021, 7022, 7051, 7052 which will be used as servers’ listening ports)
  5. Running setup script

    cd $MW_HOME/wlserver/samples/server/medrec
    ant mt.coherence.cluster.sample

Webapp URLs

After success, please access following URLs to experience MedRec:

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.