Tuesday, January 17, 2012

Weblogic 12.2.1.2: Create connection factories in a system module on Weblogic Cluster

Connection factories are objects that enable JMS clients to create JMS connections. A connection factory supports concurrent use, enabling multiple threads to access the object simultaneously.
To create a connection factory in a JMS system module:
  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit
  2. In the Administration Console, expand Services > Messaging and select JMS Modules.
  3. In the JMS Modules table, click the name of JMS module in which you want to configure the connection factory resource.
  4. On the module's Settings page, click the New button in the Summary of Resources table.
  5. On the Create a New JMS System Module Resource page, select Connection Factory from the list of JMS resources, and then click Next.
  6. On the Connection Factory Properties page, define the connection factory's basic properties:
    1. In Name, enter a name for the connection factory. Once you create a connection factory, you cannot rename it. Instead, you must delete it and create another one that uses the new name.
    2. In JNDI Name, enter a name for accessing the connection factory within the JNDI name space. Applications use the JNDI Name to look up the connection factory. If you do not specify a JNDI name for the connection factory, it will not be available for JNDI lookup even after the connection factory has been targeted to a server resource. Therefore, you will only be able to access the connection factory in an application-scoped context.
    3. In Subscription Sharing Policy, select Exclusive if all subscribers created using this connection factory cannot share subscriptions with any other subscribers. Select Sharable if subscribers created using this connection factory can share their subscriptions with other subscribers, regardless of whether those subscribers are created using the same connection factory or a different connection factory. Consumers can share a non-durable subscriptions only if they have the same Client ID and Client ID Policy; consumers can share a durable subscription only if they have the same Client ID, Client ID Policy, and Subscription Name.
    4. In Client ID Policy, select RESTRICTED if only one connection that uses this policy can exist in a cluster at any given time for a particular Client ID. Select UNRESTRICTED if connections created using this policy can specify any Client ID, even when other restricted or unrestricted connections already use the same Client ID.
    5. In Maximum Messages per Session, specify the maximum number of messages that can exist for an asynchronous session and that have not yet been passed to the message listener. When the Synchronous Prefetch Mode is enabled, this value also affects synchronous sessions with a message consumer that will prefetch messages in one server access.
    6. In XA Connection Factory Enabled, select whether an XA queue or XA topic connection factory is used, instead of a standard queue or topic connection factory. An XA factory is required for JMS applications to use JTA user-transactions, but is not required for transacted sessions.
  7. Click Next to proceed to the targeting page or click Finish to create the connection factory.
    Caution: If you click Finish at this point, the connection factory will be created but without any targeting information. As a result, the connection factory will not be deployed and thus will not be available to applications until you manually select a subdeployment target.
    On the targeting page, you can either simply accept the parent JMS system module's default targets or proceed to an advanced targeting page where you can use the subdeployment mechanism for targeting this connection factory.
  8. For basic default targeting, accept the default targets presented in the Targets box and then click Finish. The default targets are based on the parent JMS system module targets. Oracle recommends targeting a connection factory to a server or cluster, not a subdeployment. Upon clicking Finish, the configured connection factory is added to the module's Summary of Resources table, which displays its default targets. The default targeting will also be reflected by the Default Targeting Enabled checkbox on the connection factory's Configuration: General page.
  9. For advanced targeting, click Advanced Targeting, which allows you to select an existing subdeployment or to create a new one. A subdeployment is a mechanism by which JMS module resources (such as stand-alone destinations, uniform distributed destinations, and connection factories) are grouped and targeted to server resources (such as JMS servers, server instances, or cluster).
    • To select an existing subdeployment for the connection factory, select one from the Subdeployments drop-down. When a valid subdeployment is selected, its targeted JMS server(s), server(s), or cluster appear as selected in the Targets box. (A subdeployment with stand-alone destinations can only be targeted to a single JMS server.) Click Finish to add the connection factory to the selected subdeployment.
    • To create a new subdeployment for the connection factory, click the Create a new Subdeployment button. On the Subdeployment Properties page, enter a name for the subdeployment, and then click OK. On the ensuing subdeployment targeting page, select a JMS server(s), server instance(s), or cluster in the Targets box. (A subdeployment with stand-alone destinations can only be targeted to a single JMS server.) Click Finish to add the connection factory to the new subdeployment.
    Upon clicking Finish, the configured connection factory is added to the module's Summary of Resources table, which displays the user-defined subdeployment name and its targets. You can also reconfigure subdeployment targets later if you wish.
  10. To activate these changes, in the Change Center of the Administration Console, click Activate Changes













 


3 comments:

  1. Very well said, simple steps and straight to the point.

    ReplyDelete
  2. simple and straight forward..

    ReplyDelete
  3. Great post, thank you Saluja.

    Trying to better understand when to use XA connection factories, b/c only want to use them when required, as there is overhead with XA. My basic understanding is that JMS source to 1:many JMS targets does not require XA, but should use XA with DB (XA-enabled) or HTTP endpoints. Is this correct?

    Can you also clarify this statement, this was confusing for me...trying to interpret it in terms of the decision to use an XA connection factory in OSB:
    "An XA factory is required for JMS applications to use JTA user-transactions, but is not required for transacted sessions."

    ReplyDelete

ForgeRock IAM : OpenDS (Open Directory Server). Importing LDIF files

The most efficient method of importing LDIF data is to take the OpenDJ server offline. Alternatively, you can schedule a task to import the ...