Specifying the Default ESB Design Time Instance

This week I'm running a SOA HA class, and one question that usually comes up during these sessions is the one about the Oracle ESB design time instance. As you probably are aware of, this instance can only run in an Active-Passive setup (I will not dwell about the details of that in this post), so the obvious follow-up question, which isn't answered in the Enterprise Deployment Guide, is how do you specify which one of the instance you have configured and deployed the ESB design time on is going to be the default one?

Well, if you follow the instructions in the EDG 3.1.16, where you set:

<process-type id="OC4J_ESBDT" module-id="OC4J" service-failover="1" status="enabled">

you cannot really tell. If you start the instances at approximately the same time, you cannot really say which instance that will be started, for example, suppose that you have configured the instances to be brought up at boot time, and you start the machines at the same time. This might be fine, but under most circumstances you probably would like to select which one that will be the default running ESB design time instance. Well, you obviously always have the option to manually start the selected default instance first, and this problem will then go away.

Using the "service-weight" parameter can help you a bit with this task. The details of this parameter are described in the Process Manager and Notification Server Administrator's Guide. Basically, the higher value of this parameter, the higher priority to use this instance.

So, suppose that you configure the instance on machine Apa as:

<process-type id="OC4J_ESBDT" module-id="OC4J" service-failover="1" service-weight="200" status="enabled">

and the instance on machine Bepa as:

<process-type id="OC4J_ESBDT" module-id="OC4J" service-failover="1" service-weight="100" status="enabled">

OPMN will start the instance on machine Apa, given that they are started approximately at the same time. However, if the instance on machine Bepa has already been started and is up & running, and you then start the instance on machine Apa, OPMN will not bring down the instance on machine Bepa. So, using this solution will only work if the instances are started at approximately the same time.

If you really want to be sure that a specific instance is primary used, like the instance on machine Apa in the example above, you will have to create an event-script in the pre-start section for the instance running on Apa that brings down the instance running on Bepa. This way the instance on Apa will always will be used, regardless if Bepa is already running. There are some drawbacks with this solution that are documented in the OPMN documentation that you should be aware of if considering this solution.

Coherence 3.4 Developer Pre-Release Available

The Coherence 3.4 developer pre-release is now available for download. Please note that this release is only available via Oracle MetaLink for customers with CSI numbers.

Some of the new features are:

• Coherence C++ API
• New Coherence Serialization Framework
• New and Improved Coherence Data Grid Functionality
• Management Framework Enhancements
• and many, many more...

Please refer to the release notes for a full list & complete details on the new features

To obtain the Oracle Coherence 3.4 Developer Pre-Release 1 product, logon to MetaLink and lookup Note 602553.1 and follow the directions.

For further details about the Oracle Coherence 3.4 Developer Pre-Release please refer to this OTN page.

Using DirectSQL in BPEL / ESB Database Adapter

If you read the Database Adapters User's Guide you will sooner or later get to the Performance section, and there you will find DirectSQLPerformance briefly mentioned. However, it is not described in details, so here are some additional comments on this feature.


The Default Behaviour

The normal way for the Database Adapter to work is to use TopLink between the adapter and the Database. This is transparent to the end user when creating a database adapter in either ESB or BPEL. The only hint that you will get that TopLink is involved is in your source project. Here you will find a generated TopLink mapping file and some additional classes used by TopLink within your project. In most cases you will not have to worry about this at all. TopLink behaves like a good citizen within your process, and things work fine.


What is DirectSQL?

This is a feature of the Database Adapter that let it bypass the TopLink framework, and instead use direct JDBC SQL calls to the database. Well, it will not totally bypass TopLink, it will still be used for generating the SQL, obtaining connections, and table introspection. However, other functions of TopLink (for example the cache) will not be used under DirectSQL.

So, why bother about DirectSQL at all? Well it can, under some circumstances, give you better performance. I have found that it is very hard to identify these circumstances and predict when it will and when it won't improve the performance. The advice is basically just to test it, and see if improves the performance or not.


What are the Gotchas?

There are some requirements that need to be fulfilled in order for this feature to work. If you have configured DirectSQL, but some of the requirements are not fulfilled, the adapter will fallback and use TopLink. It will in these cases also log a warning message why it didn't work.

The restrictions that needs to be taken into account are listed below:

• For an Inbound Adapter you must have DeletePollingStrategy.
• For an Outbound Adapter you can only use it with Insert.
• It only works for flat table structures.
• It is limited to work with String, Number, Clob, Blob and Date & Time Types only.
• It does not work with the DetectOmissions feature.

How is it Configured?

It is configured in the adapter WSDL file:

<jca:operation
InteractionSpec="oracle.tip.adapter.db.DBWriteInteractionSpec"
DescriptorName="myService.PerfOut"
DmlType="insert"
DetectOmissions="false"
UseDirectSql="true"
OptimizeMerge="true"
MappingsMetaDataURL="myService_toplink_mappings.xml" />

Note that you in addition to setting UseDirectSql="true" you must also set DetectOmissions="false", this because DetectOmissions defaults to true.