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:
– 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:
CREATE TABLE BOXBURNER.TESTTAB
(ID NUMERIC NOT NULL,
PRIMARY KEY (ID))
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:
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.
Hebt u vragen of suggesties?
De Bruyn Kopsstraat 9
2288EC Rijswijk (ZH)
+31.(0)70 319 5000