WebLogic 12.1.2: Derby database and elastic JMS

A while ago Oracle released its new version of WebLogic Server 12.1.2 with lots of new cool features such as dynamic clustering and elastic JMS. Now there have been a lot of improvements from an administrative point of view, nevertheless JMS version is still at 1.1 (already since 2002!) Version 2.0 is out but not for this release yet.

For doing some testing I didn’t have an Oracle database present, so why not use WebLogic’s embedded database Derby?

Derby Database configuration
If you have a WebLogic environment configured and you need to test against a database, a quick and easy solution is offered to you. Shipped  from version 10.3.3 WebLogic uses Apache’s Derby database built in (previous versions were shipped with PointBase). Derby is Apache’s OpenSource database based on Java, it’s JDBC drivers and SQL. It has a small footprint so it’s ideal for lightweight operations. Very easy to set up, as you will read in this blog.

You could start the derby database ( on *nix systems) from command line. In the WebLogic server home the derby libraries, binaries and scripts are located under <WL_HOME>/common/derby.

First start the connection interface:

/u01/app/middleware_1212/wlserver/common/derby/bin/startNetworkServer -h <hostname> ( I used localhost, but better use your FQDN)

A more concise way to do is to embed this into your WebLogic domain. This can be done very easily by setting derby tor true in your setDomainEnv file:


Now, there are several ways to create a database:

– Through derby command line ij:

connect 'jdbc:derby://localhost:1527/qnlel1dbs;ServerName=localhost;databaseName=qnlel1dbs';

– In the WebLogic console, which is a very easy way



After the test is successful, and you’ve targeted the datasource to the proper servers, it is ready for use.

Now, for my test I needed to create some tables and sequences. This can be done through command line with sql:

connect 'jdbc:derby://qnlel1-JFalldemo1:1527/qnlel1dbs;ServerName=qnlel1-JFalldemo1;databaseName=qnlel1dbs';

This simple schema was for testing purposes on our Exalogic, testing an app called BoxBurner (thanks to Paul Done).

Where in previous versions,  you only could target a JMS server to a single managed server, you now can target is to a cluster! This is more understandable for admins, compared to the way it used to be. In the past, the HA came when you created JMS Modules such as distributed Queues, Connection Factories and so on.

Oracle promotes this features as Elastic (heard it at Amazon Cloud..?). The elasticity lies in the fact that you can rescale your JMS along with rescaling your Cluster, without creating new JMS Servers to every new managed server, because you have targeted it to your cluster so every new managed server will be added.

We will use the derby database as JMS store. Be aware that your derby JDBC does not support global transactions.

Now, you can create all the JMS resources in the WebLogic console, or, for automation purposes, use WLST. For this test I created a JDBC store, a JMS servers, a Connection Factory and a UDD Queue.

Creating the JDBC Persistent store, use a dedicated scheme and prefix so it’s better to identify them in the database, like this:



And you can identify them in you Derby database



Now create the JMS Server using the JDBC persistent store and target to your cluster:



Then create your system module, subDeployment, Connection Factories, Queues, Topics, whatever you need:

derby4 derby5


After this you can deploy your applications (EJB, Web ) and see using JMS and storing transactions into your derby database. Be aware that you should use this setup only as a playground and never in Production.

Now, this was a simple and quick setup of how to use the build in Derby database together with the renewed JMS. In the next blog we will see what the elasticity feature of JMS does, and how our database is holding storing our persistency needs.


Started in pharmacy, Michel made the change to IT in 1996, on a UNIX TTY terminal based computer and the MUMPS language. These days he is an Oracle Fusion Middleware Architect at Qualogy, as member of the Exalogic Squad team, with focus on technical infrastructure, Serverside solutions, installing, administering, configuring the Oracle Fusion Middleware stack. He started in 2000 as a support analyst for a big bank with BEA Tuxedo 6.5 and WebLogic 6. His experience is from integrations at telco´s. He now works mainly with Oracle WebLogic 11g and 12c, plus releases with practically all Oracle products running on top of it. In 2012 he became an Oracle ACE and wrote 2 books about WebLogic: http://www.packtpub.com/oracle-weblogic-server-11gr2-administration-essentials/book http://www.packtpub.com/oracle-weblogic-server-12c-first-look/book. This blog is also being published at: http://weblogiccommunity.com/blogs thanks to Jürgen Kress

2 Reacties op WebLogic 12.1.2: Derby database and elastic JMS

  1. Emmanuel schreef:

    Thanks for this interesting new feature.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *


Hebt u vragen of suggesties?

Mail info@qualogy.com!

De Bruyn Kopsstraat 9

2288EC Rijswijk (ZH)

The Netherlands

+31.(0)70 319 5000

  • Blog

  • Tags

  • @qualogy_news

  • @qresources

  • Reacties

  • Blijf in contact

    +31.(0)70 319 5000
    You might also likeclose