WebLogic 12.1.2 derby database and elastic jms

WebLogic 12.1.2 derby database and elastic jms

Published on: Category: Oracle

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:

DERBY_FLAG="true"
export DERBY_FLAG

Now, there are several ways to create a database:

– Through derby command line ij:

/u01/app/middleware_1212/wlserver/common/derby/bin/ij 
connect 'jdbc:derby://localhost:1527/qnlel1dbs;ServerName=localhost;databaseName=qnlel1dbs';
create=true';

– 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:

  1. CONNECT 'jdbc:derby://qnlel1-JFalldemo1:1527/qnlel1dbs;ServerName=qnlel1-JFalldemo1;databaseName=qnlel1dbs';
  2. CREATE TABLE BOXBURNER.TESTTAB
  3. (ID NUMERIC NOT NULL,
  4. CONTENT VARCHAR(25),
  5. PRIMARY KEY (ID))

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

JMS

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:

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:

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.

Michel Schildmeijer
About the author Michel Schildmeijer

Having made his start in the pharmacy sector, Michel transitioned to IT in 1996, working on a UNIX TTY terminal-based system and the MUMPS language. He currently works as a solutions architect at Qualogy, with a focus on middleware, application integration and service-oriented architecture. His passion for middleware started in 2000 when working as a support analyst for a financial institute with BEA WebLogic and Tuxedo. Michel is an expert on the WebLogic platform. He serves customers in his role as architect and advises them in all aspects of their IT landscape. He became an Oracle ACE in 2012 and wrote two books about WebLogic: Oracle WebLogic Server 11gR1 PS2: Administration Essentials and Oracle WebLogic Server 12c: First Look. He is a well-known speaker at national and international conferences and is recognised as an official Oracle Speaker. Read his blog: https://community.oracle.com/blogs/mnemonic

More posts by Michel Schildmeijer
Comments
Reply