Create and Configure Clusters on WebLogic

Before you begin

·         Install WebLogic Server on the computer on which you want to run the server.

Note: The Administration Server and all Managed Servers in a domain must be the same WebLogic Server version.

·         Create servers. A cluster always contains at least one server. You can create additional servers.

A WebLogic Server cluster consists of multiple WebLogic Server server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines. You can increase a cluster’s capacity by adding additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of WebLogic Server.

Create and Configure a Cluster:

·  In the Administration Console, expand Environment and select Clusters.

·  Click New.

·  Enter the name of the new cluster.

·  Select the Messaging Mode you wish to use for this cluster:

· When creating a cluster within a new WebLogic Server environment, it is recommended that you use the Unicast messaging type. Unicast requires less network configuration than multicast.

· If you are creating a cluster within an existing WebLogic Server environment or you need to ensure backward compatibility with older versions of WebLogic Server, you must use the Multicast messaging type. IP multicast is a simple broadcast technology that enables multiple applications to subscribe to a given IP address and port number and listen for messages.

·  If you are using the Unicast message mode, enter the Unicast Broadcast Channel. This channel is used to transmit messages within the cluster. If you do not specify a channel, the default channel is used.

·  If you are using the Multicast message mode:

§  Enter the Multicast address of the new cluster.

A multicast address is an IP address in the range from 224.0.0.0 to 239.255.255.255. The valid range is from 224.0.0.0 to 239.255.255.255. The default value used by WebLogic Server is 239.192.0.0. You should avoid using multicast addresses in the range x.0.0.1. This address must be unique to this cluster and should not be shared by other applications.

§  Enter the Multicast Port for the new cluster.

The multicast port is used by cluster members to communicate with each other. Valid values are between 1 and 65535.

·  Click OK.

·         To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
Not all changes take effect immediately—some require a restart Result

The new cluster appears in the Summary of Clusters table.

Assign Servers to Cluster:

Before you begin:

Create a cluster and any Managed Servers you want to add to a cluster. To assign server instances to a cluster:

·In the left pane of the Console, expand Environment and select Clusters.

·Select the cluster to which you want to assign servers.

·Select Servers and click Add.

·To add an existing server to a cluster:

·Select the Select an existing server and add it as a member of this cluster option.

·Select a server from the drop-down list.

Note: You cannot change the cluster of the Administration Server using the Administration Console. You cannot change the cluster or machine of a running server.

·Click Finish.

·To create a new server as part of a cluster:

·Select the Create a new server and add it to this cluster option.

·Click Next.

·Provide the following information:

· Server Name

· Server Listen Address

· Server Listen Port

·Click Finish.

The new server appears in the list of servers and is added as a member of the current cluster.

·To activate these changes, in the Change Center of the Administration Console, click Activate Changes. 
Not all changes take effect immediately—some require a restart

 After adding servers to Cluster, your console will be appear like this

What is Mutex?

          Mutex (mutual exclusion) is a memory structure that allows multiple program threads to share the same resource, such as file access - but not simultaneously. When a program is started, a mutex is created with a unique name. After this stage, any thread that needs the resource must lock the mutex from other threads while it is using the resource. The mutex is set to unlock when the data is no longer needed or the routine is finished.

Suppose a section of code is altering piece of data, while another thread, triggered by some unpredictable event, starts executing. If second thread reads from the same piece of data, the data, in the process of being overwritten, is in inconsistent and unpredictable state. If the second state tries overwriting the data, the ensuing state will probably be unrecoverable. These sections of code accessing shared data must therefore be protected, so that other processes which read from or write to the chunk of data are excluded from running.

The following table lists mutex functions and the actions they perform.

FUNCTION ACTION mutex_init Initialize a mutex. mutex_destroy Destroy a mutex. mutex_lock Lock a mutex. mutex_trylock Attempt to lock a mutex. mutex_unlock Unlock a mutex. pthread_mutex_init Initialize a mutex. pthread_mutex_destroy Destroy a mutex. pthread_mutex_lock Lock a mutex. pthread_mutex_trylock Attempt to lock a mutex. pthread_mutex_unlock Unlock a mutex.

Initialization

Mutexes are either intra-process or inter-process, depending upon the argument passed implicitly or explicitly to the initialization of that mutex. A statically allocated mutex does not need to be explicitly initialized; by default, a statically allocated mutex is initialized with all zeros and its scope is set to be within the calling process.

For inter-process synchronization, a mutex needs to be allocated in memory shared between these processes. Since the memory for such a mutex must be allocated dynamically, the mutex needs to be explicitly initialized with the appropriate attribute that indicates inter-process use.

Locking and Unlocking

A critical section of code is enclosed by a call to lock the mutex and the call to unlock the mutex to protect it from simultaneous access by multiple threads. Only one thread at a time may possess mutually exclusive access to the critical section of code that is enclosed by the mutex-locking call and the mutex-unlocking call, whether the mutex's scope is intra-process or inter-process. A thread calling to lock the mutex either gets exclusive access to the code starting from the successful locking until its call to unlock the mutex, or it waits until the mutex is unlocked by the thread that locked it.

Mutexes have ownership, unlike semaphores. Only the thread that locked a mutex, (that is, the owner of the mutex), should unlock it.

If a thread waiting for a mutex receives a signal, upon return from the signal handler, the thread resumes waiting for the mutex as if there was no interrupt.

Caveats

Mutexes are almost like data – they can be embedded in data structures, files, dynamic or static memory, and so forth. Hence, they are easy to introduce into a program. However, too many mutexes can degrade performance and scalability of the application. Because too few mutexes can hinder the concurrency of the application, they should be introduced with care. Also, incorrect usage (such as recursive calls, or violation of locking order, and so forth) can lead to deadlocks, or worse, data inconsistencies.

TRANSIENT AND DURABLE PROCESS

Transient and Durable Process

Most of us who are working in Oracle SOA has came across a common question many times,
what is transient and durable process in SOA.

As we know oracle soa uses dehydration store to store all the details of a process which has been executed, may it be a successful execution or may it be a failure each and every details are stored in the the SOA  dehydration store.
A process will be called a Transient process whose state  is not stored in SOA dehydration store or in tern we can say it is an in-memory execution. Any process which are not stored in the dehydration store we can call it a Transient process.

A process will be called a durable process which has its state stored in the soa dehydration store. By default all the BPEL process are durable process and its instances are stored in the dehydration tables.

Oracle SOA gives us flexibility to make any process transient forcefully by setting few properties.
These properties are bpel.config.inMemoryOptimization and bpel.config.completionPersistPolicy.
By setting these properties in tandem we can forcefully make a durable process transient.


Though there is some catch in this. As we know oracle SOA BPEL engine executes a process depending upon its message exchange pattern, if the process is synchronous then dehydration happens at the end of the execution or else if the process is asynchronous then the dehydration happens wherever the process encounters a dehydration point/activity ( wait , receive , pick , onAlarm , dehydrate).
We can make a synchronous process transient by setting above properties in the composite.xml provided the synchronous process does not have any dehydration points within its flow or else these properties won't work.

below is a snap of how to set these properties in the composite xml

<component name="BPELProcess" version="1.1">

   <property name="bpel.config.inMemoryOptimization" type="xs:string" many="false">true</property>

   <property name="bpel.config.completionPersistPolicy" type="xs:string" many="false">off</property>

</component>

Once these properties are set as shown above we will not be able to see the audit trail of this process from the em as the process is a transient process.

DEHYDRATION IN ORACLE BPEL

Dehydration in Oracle BPEL

Over the life cycle of a BPEL instance, the instance with its current state of execution may be saved in a database. When a BPEL instance is saved to a database, the instance is also known as being dehydrated. The database where the BPEL instance is saved is called a dehydration store.

Dehydration:

§  Storing the current status of the BPEL process(i.e. long running process, asynchronous process) into the 

§database tables is known as dehydration. SOA_INFRA schema is the dehydration store which contains tables to hold the Meta data of the process.

§  In Synchronous Process

·         Process gets dehydrated only at the end of the process.

·         Using Dehydrate activity we can explicitly dehydrate process state if required.

§  In Asynchronous Process

·         Automatically dehydrated the process based on the activities used.

Why Dehydration Occurs:

·         Long running process or processes waiting for response consumes memory and CPU

·         While waiting for the response the BPEL engine can store the process, thus freeing up server resources.

·         Over the life cycle of the BPEL instance, the instance with the current state of execution may be saved in database.

Dehydrate Activities:

·         Few activities causes the BPEL instances to be dehydrated

·         If the process is dehydrated, then transaction ends and a new transaction is started once the BPEL process resumes.

Dehydration activities:

·         Wait

·         Dehydrate (11g) / Checkpoint (10g)

·         Receive (without create instance)

·         Commit (Java embedded)

·         Pick

·         Invoke (nonBlocking property set)

·         Non-idempotent activity (Invoke, receive) is encountered. 

Types of BPEL Processes:

Oracle BPEL Process Manager uses the dehydration store database to maintain long-running asynchronous processes and their current state information in a database while they wait for asynchronous call-backs. Storing the process in a database preserves the process and prevents any loss of state or reliability if a system shuts down or a network problem occurs. There are two types of processes in Oracle BPEL Process Manager. These processes impact the dehydration store database in different ways.

·         Transient Process: 

Oracle BPEL server dehydrates the process instance only at the end of the process. If server crashes in middle of the running process instance, the instances will not be visible in EM

·         Durable Process: 

Oracle BPEL Server dehydrates the process instance in-flight at all mid-process breakpoint and non-idempotent activities, plus the end of the process. When the server crashes, this process instance appears in Oracle BPEL Control up to the last dehydration point (breakpoint activity) once the server restarts. If the server crashes before the process instance reaches the first mid-process breakpoint activity, the instance is not visible in Oracle BPEL Control after the server restarts.

An Idempotent Activity:

·         An idempotent activity is an activity that can be retried (or) Idempotent activities are those activities where the result is the same irrespective of no. of times you execute the process. Repeated invocations have the same effect as one invocation.

E.g. Read only services, Receive activity, the assign activity. 

·         A non-idempotent activity is an activity that can happen only once.

The default value of idempotent property is true. By default, in a BPEL process invoke activity is an idempotent activity, It means that the BPEL engine will not dehydrate the instance right after invoke activities. This property can be set for each partner link. If it is set to true and when you invoked a BPEL process and your environment get crashed all of a sudden then when you will restart the system the invoke will be executed again. But when we will set this property to false the BPEL engine will dehydrate the activity after the invoke and when you will start the server it will start from the last saved activity and not from the invoke activity. Thus it will enhance performance.

When Dehydration Occurs:

·         When the BPEL instance encounters a mid-process breakpoint activity (not including the initial receive).

            Activities like wait, receive, pick, and call to an async WSDL

That is where an existing BPEL instance must wait for an event, which can be either a timer expiration or message arrival. When the event occurs (the alarm expires or the message arrives), the instance is loaded from the dehydration store and execution is resumed. This type of dehydration occurs only in durable processes, which have mid-process break point activities. A transient process does not have any mid process break-point activities.

    ·         When the BPEL instance encounters a non-idempotent activity

When Oracle BPEL Server recovers after a crash, it retries the activities in the process instance. However, it should only retry the idempotent activities. Therefore, when Oracle BPEL Server encounters a non-idempotent activity, it dehydrates it. This enables Oracle BPEL Server to memorize that this activity was performed once and is not performed again when Oracle BPEL Server recovers from a crash.

·         When the BPEL instance finishes

At the end of the BPEL process, Oracle BPEL Server saves the process instance to the dehydration store, unless you explicitly configure it not to do so. This happens to both durable and transient processes.

Note: A BPEL invoke activity is by default (true) an idempotent activity, meaning that the BPEL process does not dehydrate instances immediately after invoke activities. Therefore, if idempotent is set to true and Oracle BPEL Server fails right after an invoke activity executes, Oracle BPEL Server performs the invoke again after restarting. This is because no record exists that the invoke activity has executed. This property is applicable to both durable and transient processes. If idempotent is set to false, the invoke activity is dehydrated immediately after execution and recorded in the dehydration store. If Oracle BPEL Server then fails and is restarted, the invoke activity is not repeated, because Oracle BPEL Process Manager sees that the invoke already executed.

It can be set within the bpel.xml file.
General syntax is
<partnerLinkBindings>
<property name="idempotent">true</property>
</partnerLinkBinding> 

Skipping Dehydration:

·        Skipping dehydration will increase performance with a cost of auditing.

·        By Default, all BPEL processes are dehydrated regardless of whether they are Synchronous or Asynchronous process.

·        For Synchronous processes that do not need to be durable, you can turn off the dehydration mechanism by setting the following properties at process or engine level:

·        Set inMemoryOptimization to true.

·        Set completionPersistPolicy property to faulted or Off.

·        Asynchronous process invocation messages are always saved to the dehydration store.

·        Durable processes are always dehydrated regardless of the settings of the persistence properties.

Dehydration Tables:

·        Cube_Instance: Stores the information about the composite instance that gets created.

·        Cube_scope: Stores information about the scopes and variables declared and used.

·        DLV_Message: All the incoming payload details are stored.

·        Invoke_Message: All the outgoing message payload details are stored.

·        Audit_Trail: Used to store information of the xml that is rendered in EM console.