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:

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

derby1

 

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';
CREATE TABLE BOXBURNER.TESTTAB
(ID NUMERIC NOT NULL,
CONTENT VARCHAR(25),
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:

derby2

 

And you can identify them in you Derby database

derby3

 

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

derby4

 

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.

OVER DE AUTEUR

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.

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 *

De volgende HTML-tags en -attributen zijn toegestaan: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Contact

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