JTA Transactions - Local and Global Transaction. And example with Oracle BPEL Application.

This Blog is about understanding the basics of transaction in J2EE level and how this can be translated to Oracle, BPEL conceptually. This does not limit the interpolation of this concept in simple Java projects as well.

Now lets dig in...


Transactions

J2EE supports two kinds of transactions:

• Local Transactions - A local transaction is internal to a single resource.
• Global Transactions - A global transaction is created by an external transaction manager (JTA) and is used to scope work on multiple resources.
  

Local Transactions

When a managed data source is configured for local transactions it returns connections that can participate in local transactions but cannot participate in global transactions. This means that the connections will not be enlisted in global transactions. The data source will set the auto commit to true for retrieved connections. However, it is up to the client to determine how the connections will be used in local transactions. That is, the client can change the auto-commit mode by using setAutoCommit() on a connection.


Local transactions are transactions associated with a particalar data source (means they are resource-specific). the most common example would be a transaction associated with a JDBC connection.

Global Transactions (XA)

When a managed data source is configured for global transactions, it returns connections that can participate in global transactions. A global transaction (also called a distributed transaction) enlists more than one resource in the transaction.

Global Transactions provide the ability to work with multiple transactional resources (typically relational databases and message queues).

Sources:
Oracle® Containers for J2EE Services Guide 10g (10.1.3.1.0)
Question: Difference between local and global transaction ? - AllInterview


Now putting this in SOA, Concept for better understanding:

Diag Source: Oracle® Containers for J2EE Services Guide 10g (10.1.3.1.0)Part Number B28958-01

So with the above image, lets make some assumptions,

hint: BPEL needs a JDBC connection for its dehydration purpose.

The client Tx is the main BPEL process and the new Tx is probably the adapter / another BPEL process invocation process with in the main BPEL process.


In a local transaction setup, client Tx will be a separate transaction and new Tx will be on its own.
In a global transaction setup, new Tx will be a part of or will participate with client Tx.

In another scenario, we can have one client Tx as local and two new Tx as XA. In this scenario the BPEL process will be on tis own and the two new  Tx will be part of one global Tx.

for example this case will apply where you have one BPEL process and you have two or more DB adapters in the BPEL process. Which means, all the DB adapter Tx will roll back if any one of the DB adapters fail with an error.


Additional Info:

Source: Local and global transaction considerations - IBM docs

Local and global transaction considerations

Applications use resources, such as Java Database Connectivity (JDBC) data sources or connection factories, that are configured through the Resources view of the administrative console. How these resources participate in a global transaction depends on the underlying transaction support of the resource provider.

For example, most JDBC providers can provide either XA or non-XA versions of a data source. A non-XA data source can support only resource manager local transactions (RMLT), but an XA data source can support two-phase commit coordination, as well as local transactions.

If an application uses two or more resource providers that support only RMLTs, atomicity cannot be assured because of the one-phase nature of these resources. To ensure atomic behavior, the application should use resources that support XA coordination and should access them within a global transaction.
If an application uses only one RMLT, atomic behavior can be guaranteed by the resource manager, which can be accessed in a local transaction containment (LTC) context.

An application can also access a single resource manager in a global transaction context, even if that resource manager does not support the XA coordination. An application can do this because the application server performs an "only resource optimization" and interacts with the resource manager in a RMLT. In a global transaction context, any attempt to use more than one resource provider that supports only RMLTs causes the global transaction to be rolled back.

At any moment, an instance of an enterprise bean can have work outstanding in either a global transaction context or an LTC context, but not both. An instance of an enterprise bean can change from running in one type of context to the other (in either direction), if all outstanding work in the original context is complete. Any violation of this principle causes an exception to be thrown when the enterprise bean tries to start the new context.

What is a durable subscription - JMS.

 A durable subscription saves messages for an inactive subscriber and deliveres these saved messages when the subscriber reconnects. In this way, a subscriber will not loose any messages even though it disconnected. A durable subscription has no effect on the behavior of the subscriber or the messaging system while the subscriber is active (e.g., connected). A connected subscriber acts the same whether its subscription is durable or non-durable. The difference is in how the messaging system behaves when the subscriber is disconnected.

Use a Durable Subscriber to make the messaging system save messages published while the subscriber is disconnected.

Source:  http://www.eaipatterns.com/DurableSubscription.html

The durable subscription only apply to the topic of the JMS.

JMS Queue - Difference between a Queue and a Topic.

This is a typical interview question: What is the difference between a Queue and a Topic ( or Queue Vs Topic).

Before you go for the comparisons you need to learn the basics such as what is a JMS Queue what was the purpose of this technology and so on...

I would like to point you to this wiki page:

Topic: Java Message Service


After you have reviewed the above page you might have understood what is the difference already. But for those who are time short... read on.

First Elements of an JMS Queue:

JMS provider
    An implementation of the JMS interface for a Message Oriented Middleware (MOM). Providers are implemented as either a Java JMS implementation or an adapter to a non-Java MOM.

JMS client    An application or process that produces and/or receives messages.

JMS producer/publisher    A JMS client that creates and sends messages.

JMS consumer/subscriber
    A JMS client that receives messages.

JMS message
    An object that contains the data being transferred between JMS clients.

JMS queue
    A staging area that contains messages that have been sent and are waiting to be read. Note that, contrary to what the name queue suggests, messages have to be delivered in the order sent A JMS queue only guarantees that each message is processed only once.

JMS topic    A distribution mechanism for publishing messages that are delivered to multiple subscribers. 

Source: Java Message Service

The comparison: Queue VS Topic

Queue:

• Point-to-point model
• Only one consumer gets the message
• Messages have to be delivered in the order sent
• A JMS queue only guarantees that each message is processed only once.
• The Queue knows who the consumer or the JMS client is. The destination is known.
• The JMS client (the consumer) does not have to be  active or connected to the queue all the time to receive or read the message.
• Every message successfully processed is acknowledged by the consumer.

Descriptive example: A JMS queue is a channel through which users "pull" messages they want to receive using the p2p model, instead of automatically receiving messages on a particular topic. The producer submits messages to the queue, and recipients can browse the queue and decide which messages they wish to receive. In the p2p model, users can see the contents of the messages held in the queue before deciding whether or not to accept their delivery.

Read more: JMS Queue vs. JMS Topic | eHow.com

 
Topic:

• Publish/subscribe model
• Multiple clients subscribe to the message
• There is no guarantee messages have to be delivered in the order sent
• There is no guarantees that each message is processed only once. -- As this can be sensed from the model 
• The Topic, have multiple subscribers and there is a chance that the topic does not know all the subscribers. The destination is unknown.
• The subscriber / JMS client needs to the active when the messages are produced by the producer, unless the subscription was a durable subscription.
• No, Every message successfully processed is not acknowledged by the consumer/subscriber.

Descriptive Example: A JMS topic is the channel through which users subscribe to receive specific messages from a producer in the publish-and-subscribe model of JMS messaging. The model can be compared to subscribing to a newspaper; for example, if John Doe subscribed to "The New York Times," he would receive the paper every day from the newspaper producer. Similarly, if John Doe used JMS messaging to subscribe to a particular topic, he would receive all sent messages from a producer regarding that topic.

Read more: JMS Queue vs. JMS Topic | eHow.com

How to Collect Thread dump for Oracle Applications - In this Case B2B 10g in Linux.

The command to perform a thread dump on linux is kill -3 <pid>. 


The <pid> can be found using opmnctl status for the midtier. 


Example of the output:


-------------------+--------------------+---------+---------
ias-component      | process-type       |     pid | status -------------------+--------------------+---------+--------- LogLoader          | logloaderd         |     N/A | Down   dcm-daemon         | dcm-daemon         |     N/A | Down   OC4J               | home               |    1648 | Alive  HTTP_Server        | HTTP_Server        |    1646 | Alive  B2B                | B2BServer          |    1647 | Alive  B2B                | OC4J_B2B           |    1649 | Alive  DSA                | DSA                |     N/A | Down   


In the above example, the <pid> is 1647.


The thread dumps are located in file $ORACLE_HOME/opmn/logs/B2B~B2BServer~*  or B2B~OC4J_B2B~* file. 


This needs to be done a least three times at interval about 15-30 seconds each after the issue (what ever you are debugging) has been re-produced. 


Example of a thread dump:


Full thread dump Java HotSpot(TM) Server VM (1.4.2_14-b05 mixed mode):

"Thread-9" prio=1 tid=0x088d0110 nid=0x22b8 runnable [0x857ab000..0x857ac228]
       at java.net.SocketInputStream.socketRead0(Native Method)
       at java.net.SocketInputStream.read(SocketInputStream.java:129)
       at oracle.net.ns.Packet.receive(Unknown Source)
       at oracle.net.ns.DataPacket.receive(Unknown Source)
       at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
       at oracle.net.ns.NetInputStream.read(Unknown Source)
       at oracle.net.ns.NetInputStream.read(Unknown Source)
       at oracle.net.ns.NetInputStream.read(Unknown Source)
       at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:978)
       at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:950)
       at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:447)
       at oracle.jdbc.driver.T4CCallableStatement.doOall8(T4CCallableStatement.java:183)
       at oracle.jdbc.driver.T4CCallableStatement.execute_for_rows(T4CCallableStatement.java:872)
       at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1160)
       at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3000)
       at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3042)
       - locked <0x91feaae8> (a oracle.jdbc.driver.T4CCallableStatement)
       - locked <0x91e29b38> (a oracle.jdbc.driver.T4CConnection)
       at oracle.jms.AQjmsConsumer.dequeue(AQjmsConsumer.java:1601)
       at oracle.jms.AQjmsConsumer.receiveFromAQ(AQjmsConsumer.java:922)
       at oracle.jms.AQjmsConsumer.receiveFromAQ(AQjmsConsumer.java:835)
       at oracle.jms.AQjmsConsumer.receive(AQjmsConsumer.java:776)
       at oracle.tip.adapter.b2b.data.MsgListener.run(MsgListener.java:366)
       at java.lang.Thread.run(Thread.java:534) 

ServerURL and Callback Server URL in SOA 11g, 10G

This question or need for setting property really arises when you want a cluster setup or predominantly when you have a software or a hardware load-balancer which takes the requests and routs.


In 10g We would configure this Call back url and server URL by following steps:

1. Set the soapServerURL and the soapCallbackUrl to the same value as the load balancer URL:
   
   1. Open the ORACLE_HOME/bpel/system/config/collaxa-config.xml file.
   2. Set the soapServerUrl and soapCallbackUrl to the HTTPS URL, so that the entries resemble the following:
      

      ...
          <property id="soapServerUrl">
              <name>BPEL soap server URL</name>
                 <value>https://soa.mycompany.com</value>
      ...
          </property>
      ...
          <property id="soapCallbackUrl">
              <name>BPEL soap callback URL</name>
                 <value>https://soa.mycompany.com</value>
      ...
          </property>
      

2. Restart the OC4J_SOA instances on both computers.

Source: Oracle® Application Server Enterprise Deployment Guide 10g Release 3 (10.1.3.1.0)
Part Number B28939-03
Section: Section: 3.1.12 Configuring the Cluster of BPEL Instances

Now the same can be achieved in 11g by following the steps from:

1. Right Click on SOA-INFRA component in the left navigation tree. Go to Soa Administration --> Common Properties 

2. Set the CallBackServerURL and the ServerURL to  http://deskLinux:8001 and click Save button

3. Restart SOA server to activate the changes . The URL should now be modified for all composites.


Source: Thanks to Mihai's Blog.
ServerURL and Callback Server URL in SOA 11g

Reference:
Document: Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite 11g Release 1 (11.1.1)
Part Number E12036-01

Section: 5.17 Setting the Frontend HTTP Host and Port - Callback URL

Configurable Properties and Reference Binding for Oracle JCA adapters 11g

If you would like to know what are all the configurable properties and reference binding for oracle JCA adapters 11g

Please refer this document:

Oracle® Fusion Middleware Administrator's Guide for Oracle SOA Suite 11g Release 1 (11.1.1)

Section: 33 Configuring Service and Reference Binding Components


Source: Oracle Documentation. OTN.

This included, but not limited to, configuration properties for: DB adapter, File Adapter, FTP Adapter, AQ Adapter, MQ Series Adapter, Oracle Socket Adapter, Oracle JCA Adapters Endpoint Properties.

Difference between Sync and Async BPEL process -- Well explained.

This below blog contains all the essential to differentiate or understand the differences between the Sync and Asyn BPEL process.

Difference between Sync and Async BPEL process - anindyabhattacharjee

Well explained Anindya. Hats off.....

Just for quick reference and to find the differences: if you look in to the source code of the .BPEL file you will find the following respective to the to different BPEL process:

Async BPEL process will contain:  Receive and Invoke for the call back.

 <sequence name="main">
        <!-- Receive input from requestor. (Note: This maps to operation defined in BPELProcess1_Async.wsdl) -->
        <receive name="receiveInput" partnerLink="bpelprocess1_async_client" portType="client:BPELProcess1_Async" operation="process" variable="inputVariable" createInstance="yes"/>
        <!--
          Asynchronous callback to the requester. (Note: the callback location and correlation id is transparently handled using WS-addressing.)
        -->
        <invoke name="callbackClient" partnerLink="bpelprocess1_async_client" portType="client:BPELProcess1_AsyncCallback" operation="processResponse" inputVariable="outputVariable"/>
    </sequence>

Sync BPEL process will contain: Receive and a Reply.

  <sequence name="main">
    <!-- Receive input from requestor. (Note: This maps to operation defined in Sync_realSync.wsdl) -->
    <receive name="receiveInput" partnerLink="sync_realsync_client" portType="client:Sync_realSync" operation="process" variable="inputVariable" createInstance="yes"/>
    <!-- Generate reply to synchronous request -->
    <reply name="replyOutput" partnerLink="sync_realsync_client" portType="client:Sync_realSync" operation="process" variable="outputVariable"/>
  </sequence>