Weblogic jms file store

This policy is the fastest, but the least reliable that is, transactionally safe. Cache-Flush - Transactions cannot complete until all of their writes have been flushed down to disk. This policy is reliable and scales well as the number of simultaneous users increases.

Direct-Write - File store writes are written directly to disk. This policy is supported on Solaris and Windows.

If this policy is set on an unsupported platform, the file store automatically uses the Cache-Flush policy instead. With on-disk caching enabled, the Direct-Write policy can be times faster than the Cache-Flush policy, except in highly scalable cases where it may be slightly slower. With on-disk caching disabled, the Direct-Write policy is faster than the Cache-Flush policy in one-to-many cases, but is much slower otherwise.

An SQL command can span several lines and is terminated with a semicolon ;. Lines beginning with pound signs are comments. Save your changes and rename the new DDL appropriately for example, mydatabase.

The JDBC utils. Running this utility is usually not necessary, since WebLogic Server automatically creates this table for you. However, if your existing JDBC store database table somehow becomes corrupted, you can delete it using the utils.

Schema utility. The utils. Schema utility is a Java program that takes command-line arguments to specify the following:. Table Command-line arguments for utils. Database connection URL. You can also specify the -verbose option, which causes utils. Schema to echo SQL commands as they are executed. The JDBC store provides an optional Prefix Name parameter, which can be used to provide more precise access to the database table.

The database requires fully-qualified names. You should verify this with your database administrator. There are many tables in the database. Setting the prefix reduces the number of tables the JDBC store must search through to find its table during boot. Note that each period in the [[[catalog. Generally, catalog identifies the set of system tables being referenced by the DBMS, and schema generally corresponds to ID of the table owner username.

For example, in a production database, the database administrator could maintain a unique table for the Sales department, as follows:. For some DBMS vendors, such as Oracle, there is no catalog to set or choose, so the format simplifies to [[schema. For more information, refer to your DBMS documentation for instructions on fully-qualified table names, but note that the syntax specified by the DBMS may differ from the format required for this option.

WebLogic Server provides robust JDBC data sources that can automatically reconnect to failed databases after they come back online, without requiring you to restart WebLogic Server. That is, the store itself implements the XAResource and handles the transactions without depending on the database even when the messages are stored in the database.

This means that whenever you are using a JDBC store and a database even if it is the same database where the JMS messages are stored , then it is two-phase commit transaction. Ensure that the JDBC data source used for the database work exists on the same server instance as the JMS destination - the transaction will still be two-phase, but it will be handled with less network overhead.

Configure multiple services to share the same store if they will commonly be invoked within the same transaction. If an application directly performs database operations in addition to invoking store services such as JMS within the same transaction, consider using a JDBC data source with Logging Last Resource LLR enabled for the database operations.

With the LLR optimization, the transaction will follow the two-phase commit protocol, but the database operations will be handled in a single local transaction, which may improve overall transaction performance.

You can monitor statistics for each existing persistent store and for each open store connection. Each persistent store is represented at runtime by an instance of the PersistentStoreRuntimeMBean , which provides the following options. Table Persistent Store Run-time Options. For each open persistent store connection, the persistent store also registers a PersistentStoreConnectionRuntimemMBean , which provides the following options. Table defines most of the runtime prefix names of the WebLogic services and subsystems that can create a connection to the persistent store.

The WebLogic Store administration utility enables administrators to troubleshoot a WebLogic persistent store. The store utility operates only on a store that is not currently opened by a running server instance.

The most common uses-cases for store administration are for compacting a file store to reduce its size and for dumping the contents of a file store of JDBC store to an XML file for troubleshooting purposes. Examples of these use cases are provided later in this section. Table Persistent Store Administration Options. Compacts and defragments the space occupied by a file store. This command only works offline and does not work for JDBC stores.

Note: Compacting a file store is usually not necessary if you know that file store will likely grow to the current size again. File stores automatically re-use space freed by deleted records and expand only when there is insufficient internal space for new records. Also, file stores do not normally become fragmented as most persistent records are short-lived. Opens an existing file store for further operations. If a file store does not exist, a new one is created in an open state using the -create parameter.

Opens an existing JDBC store for further operations. If a JDBC store does not exist, a new one is created in an open state. Dumps store or connection contents in a human-readable format to user-specified XML file. The XML file format is the same format used by the diagnostic image of the persistent store. Most commands and methods work in terms of store names, while others also work in terms of connection names.

Store connections are logical groups of records within persistent stores. To open the persistent store administration utility from a Java command-line, type the following:. Type help for detailed descriptions on available store administration commands, as well as examples of typical command usage. For example, the following comprehensive help is provided for the list command, which lists store names, open stores, or connections in a store.

Here's an example of using a series of store administration commands to ultimately export the contents of a file store named myfilestore into a human-readable XML file format in a temporary directory. This does not include store connection names or the actual record contents, which require the optional -conn and -deep parameters.

The list command shows all the store names in the current directory. After administering an open store, you must close it using the close command. Here's an example of using the compact command to compact the space occupied by a file store in the mystores directory. Since the compact command can only be used on an unopened file store, none of the stores that have files in the source -dir directory should be open. Also, the temporary -tempdir directory should have at least enough extra space as the source directory and should also not be under the source directory.

When compact successfully completes, the newly compacted store files will be in the mystores directory. In addition, a new, uniquely-named directory will be created under tmp containing the original uncompacted store files. The WLST interface has a couple of additional methods compared to the Java command-line such as getopenstores and getstoreconns , that return relevant Java objects and can be used for scripting in WLST.

Type helpstore for detailed descriptions on available store administration commands, as well as examples of typical command usage. Another distinction when using the default connection factories is that you have no control over targeting the WebLogic Server instances where the connection factory may be deployed.

However, you can disable the default connection factories on a per-server basis. To deploy a connection factory on specific independent servers, on specific servers within a cluster, or on an entire cluster, you must configure a new connection factory and specify the appropriate target, as explained in Connection Factory Configuration in Administering JMS Resources for Oracle WebLogic Server.

The JNDI names for these factories are javax. QueueConnectionFactory and javax. A system administrator can define and configure one or more connection factories to create connections with predefined attributes and WebLogic Server will add them to the JNDI space during startup. Any user-defined connection factories must be uniquely named. A system administrator establishes cluster-wide, transparent access to JMS destinations from any server in the cluster by targeting to the cluster or by targeting to one or more server instances in the cluster.

This way, each connection factory can be deployed on multiple WebLogic Server instances. The ConnectionFactory class does not define methods; however, its subclasses define methods for the respective messaging models. For this release, you can use the JMS version 1.

Table describes the ConnectionFactory subclasses. A Connection represents an open communication channel between an application and the messaging system, and is used to create a Session see Session for producing and consuming messages. A connection creates server-side and client-side objects that manage the messaging activity between an application and JMS. A connection may also provide user authentication. Due to the resource overhead associated with authenticating users and setting up communications, most applications establish a single connection for all messaging.

Servlets and other server-side objects can also obtain JMS Connections. By default, a connection is created in stopped mode. For information about how and when to start a stopped connection, see Starting, Stopping, and Closing a Connection.

Connections support concurrent use, enabling multiple threads to access the object simultaneously. For this release, you can use the JMS Version 1.

Table describes the Connection subclasses. A Session object defines a serial order for the messages produced and consumed, and can create multiple message producers and message consumers. The same thread can be used for producing and consuming messages. If you want an application to have a separate thread for producing and consuming messages, then the application should create a separate session for each function.

A Session is created by Connection see Connection. The JMS 1. In addition, having multiple consumers for a single session is not a common practice. The following commonly used scenarios are supported:. A session and its message producers and consumers can only be accessed by one thread at a time.

Their behavior is undefined if multiple threads access them simultaneously. Table describes the Session subclasses. Created by TopicConnection. WLSession Javadoc. In a non-transacted session, the application creating the session selects one of the five acknowledge modes defined in Table The Session object acknowledges receipt of a message after receiving application method has returned from processing it.

The Session object relies on the application to call an acknowledge method on a received message. After the method is called, the session acknowledges all messages received since the last acknowledge. This mode allows an application to receive, process, and acknowledge a batch of messages with one call.

Note: In the WebLogic Server Administration Console, if the Acknowledge Policy attribute on the connection factory is set to Previous , but you want to acknowledge all received messages for a given session, then use the last message to invoke the acknowledge method. The Session object acknowledges receipt of a message after the receiving application method has returned from processing it; duplicate acknowledges are permitted.

Note: You should avoid using this mode if your application cannot handle duplicate messages. Duplicate messages may be sent if an initial attempt to deliver a message fails.

No acknowledgement is required. This mode is supported for applications that do not require the quality of service provided by session acknowledge, and that do not want to incur the associated overhead.

Note: You should avoid using this mode if your application cannot handle lost or duplicate messages. This mode is supported for applications that want to support multicasting, and that do not require the quality of service provided by session acknowledge. Note: Use only with topics. You should avoid using this mode if your application cannot handle lost or duplicate messages. In a transacted session, only one transaction is active at any time. Any number of messages sent or received during a transaction are treated as an atomic unit.

When you create a transacted session, the acknowledge mode is ignored. When an application commits a transaction, all the messages that the application received during the transaction are acknowledged by the messaging system and messages it sent are accepted for delivery.

If an application rolls back a transaction, then the messages that the application received during the transaction are not acknowledged and messages it sent are discarded.

Transacted sessions do not support this capability because the transaction is restricted to accessing the messages associated with that session. A Destination object can be either a queue or topic, encapsulating the address syntax for a specific provider.

The JMS specification does not define a standard address syntax due to the variations in syntax between providers. Similar to a connection factory, an administrator defines and configures the destination, and WebLogic Server adds it to the JNDI space during startup. Applications can also create temporary destinations that exist only for the duration of the JMS connection in which they are created. Administrators can also configure a distributed destination, which is a single set of destinations queues or topics that are accessible as a single, logical destination to a client.

For more information, see Distributed Destinations. On the client side, Queue and Topic objects are handles to the object on the server. Their methods only return their names. To access them for messaging, you create message producers and consumers that attach to them.

A destination supports concurrent use, enabling multiple threads to access the object simultaneously. JMS Queue and Topic objects extend javax. Table describes the Destination subclasses. JMS point-to-point provider, and exists for the duration of the JMS connection in which the messages are created. A temporary queue can be consumed only by the queue connection that created it. A temporary topic can be consumed only by the topic connection that created it.

An application has the option of browsing queues by creating a QueueBrowser object in its queue session. This object produces a snapshot of the messages in the queue at the time the queue browser is created. The application can view the messages in the queue, but the messages are not considered read and are not removed from the queue. A distributed destination resource is a single set of destinations queues or topics that are accessible as a single, logical destination to a client for example, a distributed topic has its own JNDI name.

The members of the set are typically distributed across multiple servers within a cluster, with each member belonging to a separate JMS server. Applications that use a distributed destination are more highly available than applications that use standalone destinations because WebLogic JMS provides load balancing and failover for the members of a distributed destination in a cluster.

For more information about using a distributed destination with your applications, see Using Distributed Destinations. For instructions about configuring a distributed queue destination, see Configure uniform distributed queues in the Oracle WebLogic Server Administration Console Online Help.

For instructions about configuring a distributed topic destination, see Configure uniform distributed topics in the Oracle WebLogic Server Administration Console Online Help. A MessageProducer sends messages to a queue or topic. A MessageConsumer receives messages from a queue or topic.

For example, this can happen when a file store gets an error from a file system or when a JDBC store cannot access its database. Messages persisted prior to a store shutdown are unavailable for consumption until either the store is restarted or is migrated to another server within the same cluster. Option 1: Explicitly configure the store Restart In Place setting to true. This causes the Restart In Place setting to default to true.

It is not possible to enable Restart In Place on stores that are directly targeted to a server within a cluster. Oracle recommends targeting stores and their dependent services to the cluster or to a migratable target instead.

Service Restart In Place can be configured independently of whole server migration or service migration. When Restart In Place and migration are both configured, they work as follows:.

If Restart In Place is enabled, if the store's original host JVM is still running, and if a failed store is configured to migrate from one server to another within a WebLogic cluster, then the system tries to restart the store on its original host JVM before it tries a migration.

If a globally-scoped store is targeted to a standalone server, is targeted to a server within a cluster, or is targeted to a cluster and has a MigrationPolicy of Off, then the store places its host WebLogic Server instance in a failed health state after all of its restart attempts fail.

If a store is scoped to a partition, is targeted to a cluster and has a MigrationPolicy of Always or On-Failure , or is targeted to a Migratable Target that enables restart-on-failure, then a failed store does not cause a WebLogic Server to enter a Failed health state even after all of its restart attempts fail as migration will kick in.

Whole server migration and whole server restart do not apply in this case. To handle the situation automatically, you can develop custom WLST scripts that do the same. Failed default stores cause a server to enter a Failed health state, and require a Whole Server Migration or Whole Server restart to recover. Oracle recommends that you configure services to persist critical information in custom stores instead of default stores. Messaging Bridges ignore Restart In Place settings.

Instead, they automatically handle failures by periodically retrying when they fail to connect to their source or target destinations. Custom JDBC Stores have an additional internal retry mechanism that takes effect first before they shutdown and requires the store and its dependent services to restart. This functionality is helpful for silent recovery from brief database outages.

If you have applications that need access to persistent stores that reside on remote machines after the migration of a JMS server or JTA transaction log, then you should implement one of the following highly-available storage solutions:.

Persistent file stores that may migrate to a different JVM or machine must be explicitly configured to reference a shared directory. For example, if for some reason the file system containing a file store is unmounted and then remounted, attempts to send persistent JMS messages will generate JMS exceptions until the host server is rebooted.

Applications can then take advantage of any high-availability or failover solutions offered by your database vendor. For more information, see:. Any persistent store—Use high-availability clustering software which provides an integrated, out-of-the-box solution for WebLogic Server-based applications. A persistent file store should not be opened simultaneously by two server instances; otherwise, there is no guarantee that the data in the file will not be corrupted. If possible, the persistent store will attempt to return an error in this case, but it will not be possible to detect this condition in every case.

It is the responsibility of the administrator to ensure that the persistent store is being used in an environment in which multiple servers will not try to access the same store at the same time.

Two file stores are considered the "same store" if they have the same name and the same directory. Two JDBC stores must not share the same database table, because this will result in data corruption. A JDBC store will normally prevent this from happening by detecting if a backing table has already been opened by another instance, but it is not possible to detect this condition in every case. Two JDBC stores can reference the same table if they have the same table name prefix and database schema.

A persistent store may not survive arbitrary corruption. If the disk file is overwritten with arbitrary data, then the results are undefined.