WebLogic Server 8.1 API Reference

weblogic.management.configuration
Interface JMSFileStoreMBean

public interface JMSFileStoreMBean

extends JMSStoreMBean

This class represents a disk-based JMS file store that stores persistent messages and durable subscribers in a file-system directory.

Author:

Copyright © 2004 BEA Systems, Inc. All Rights Reserved.

Field Summary

static long

CACHING_STUB_SVUID

Fields inherited from class weblogic.management.configuration.JMSStoreMBean

CACHING_STUB_SVUID

Fields inherited from class weblogic.management.configuration.ConfigurationMBean

CACHING_STUB_SVUID, DEFAULT_EMPTY_BYTE_ARRAY

Method Summary

java.lang.String	getDirectory() Defines the pathname to the valid file-system directory where the JMS file store is kept.
java.lang.String	getSynchronousWritePolicy() A user-defined policy that determines how the JMS file store writes data to disk.
void	setDirectory(java.lang.String directory) Defines the pathname to the valid file-system directory where the JMS file store is kept.
void	setSynchronousWritePolicy(java.lang.String policy) A user-defined policy that determines how the JMS file store writes data to disk.

Methods inherited from interface weblogic.management.configuration.JMSStoreMBean

getJMSServer

Methods inherited from interface weblogic.management.configuration.ConfigurationMBean

freezeCurrentValue, getNotes, restoreDefaultValue, setComments, setDefaultedMBean, setNotes, setPersistenceEnabled

Methods inherited from interface weblogic.management.WebLogicMBean

getMBeanInfo, getName, getObjectName, getParent, getType, isCachingDisabled, isRegistered, setName, setParent

Methods inherited from interface javax.management.DynamicMBean

getAttribute, getAttributes, invoke, setAttribute, setAttributes

Methods inherited from interface javax.management.MBeanRegistration

postDeregister, postRegister, preRegister

Methods inherited from interface javax.management.NotificationBroadcaster

addNotificationListener, getNotificationInfo, removeNotificationListener

Field Detail

CACHING_STUB_SVUID

public static final long CACHING_STUB_SVUID

Method Detail

getDirectory

public java.lang.String getDirectory()

Defines the pathname to the valid file-system directory where the JMS file store is kept.

This attribute is not dynamically configurable.

Returns:

The directory value

setDirectory

public void setDirectory(java.lang.String directory)
                  throws javax.management.InvalidAttributeValueException

Defines the pathname to the valid file-system directory where the JMS file store is kept.

This attribute is not dynamically configurable.

Legal Value: value != void && value.trim().length() != 0

Legal NULL: false

Parameters:

directory - The new directory value

Throws:

javax.management.InvalidAttributeValueException -

getSynchronousWritePolicy

public java.lang.String getSynchronousWritePolicy()

A user-defined policy that determines how the JMS file store writes data to disk. This policy also affects the JMS file store's performance, scalability, and reliability. The valid policy options are:

Disabled - Transactions are complete as soon as their writes are cached in memory, instead of waiting for the writes to successfully reach the disk. This policy is the fastest, but the least reliable (that is, transactionally safe). It can be more than 100 times faster than the other policies, but power outages or operating system failures can cause lost and/or duplicate messages.

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, HP-UX, and Windows. If this policy is set on an unsupported platform, the file store automatically uses the Cache-Flush policy instead.
The Direct-Write policy’s reliability and performance depend on the platform’s use of on-disk caches with respect to direct writes. For example, UNIX systems do not use on-disk caches for direct writes, while Windows systems generally do. The following points illustrate the pros and cons of using on-disk caching (when possible) with this policy:

• With on-disk caching enabled, the Direct-Write policy can be 2-5 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.

• The Direct-Write policy scales well with on-disk caching enabled, but does not scale with it disabled. (Solaris does not allowing enabling the on-disk cache for direct writes).

Warning! Although the use of the Direct-Write policy is transactionally reliable on Solaris and HP systems, Windows systems may leave transaction data in the on-disk cache without writing it to disk immediately. This is not considered to be transactionally reliable, since a power failure can cause loss of on-disk cache data-- possibly resulting in lost and/or duplicate messages. For reliable writes using Direct-Write on Windows, either disable all write caching for the disk (enabled by default), or use a disk with a battery-backed cache. Some file systems, however, do not allow this value to be changed (for example, a RAID system that has a reliable cache).

To disable the on-disk cache for a disk drive on Windows 2000:

1. Open the Control Panel -> System Properties dialog box.
2. Select the Hardware tab.
3. Click the Device Manager button.
4. Expand the Disk Drives node on the Device Manager tree.
5. Double-click the drive name that you want to modify.
6. On the Properties dialog box, select the Disk Properties tab.
7. Clear the Write Cache Enabled check box.

Note: If the JMS file store is used exclusively for paging non-persistent messages to disk, the Synchronous Write Policy is ignored.

A dynamic MBean attribute

Default Value: JMSConstants.SYNCWRITE_CACHEFLUSH

Legal Values: JMSConstants.SYNCWRITE_DISABLED,JMSConstants.SYNCWRITE_CACHEFLUSH,JMSConstants.SYNCWRITE_DIRECTWRITE

Returns:

The synchronousWritePolicy value

setSynchronousWritePolicy

public void setSynchronousWritePolicy(java.lang.String policy)
                               throws javax.management.InvalidAttributeValueException,
                                      DistributedManagementException

A user-defined policy that determines how the JMS file store writes data to disk. This policy also affects the JMS file store's performance, scalability, and reliability. The valid policy options are:

Disabled - Transactions are complete as soon as their writes are cached in memory, instead of waiting for the writes to successfully reach the disk. This policy is the fastest, but the least reliable (that is, transactionally safe). It can be more than 100 times faster than the other policies, but power outages or operating system failures can cause lost and/or duplicate messages.

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, HP-UX, and Windows. If this policy is set on an unsupported platform, the file store automatically uses the Cache-Flush policy instead.
The Direct-Write policy’s reliability and performance depend on the platform’s use of on-disk caches with respect to direct writes. For example, UNIX systems do not use on-disk caches for direct writes, while Windows systems generally do. The following points illustrate the pros and cons of using on-disk caching (when possible) with this policy:

• With on-disk caching enabled, the Direct-Write policy can be 2-5 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.

• The Direct-Write policy scales well with on-disk caching enabled, but does not scale with it disabled. (Solaris does not allowing enabling the on-disk cache for direct writes).

Warning! Although the use of the Direct-Write policy is transactionally reliable on Solaris and HP systems, Windows systems may leave transaction data in the on-disk cache without writing it to disk immediately. This is not considered to be transactionally reliable, since a power failure can cause loss of on-disk cache data-- possibly resulting in lost and/or duplicate messages. For reliable writes using Direct-Write on Windows, either disable all write caching for the disk (enabled by default), or use a disk with a battery-backed cache. Some file systems, however, do not allow this value to be changed (for example, a RAID system that has a reliable cache).

To disable the on-disk cache for a disk drive on Windows 2000:

1. Open the Control Panel -> System Properties dialog box.
2. Select the Hardware tab.
3. Click the Device Manager button.
4. Expand the Disk Drives node on the Device Manager tree.
5. Double-click the drive name that you want to modify.
6. On the Properties dialog box, select the Disk Properties tab.
7. Clear the Write Cache Enabled check box.

Note: If the JMS file store is used exclusively for paging non-persistent messages to disk, the Synchronous Write Policy is ignored.

A dynamic MBean attribute

Default Value: JMSConstants.SYNCWRITE_CACHEFLUSH

Legal Values: JMSConstants.SYNCWRITE_DISABLED,JMSConstants.SYNCWRITE_CACHEFLUSH,JMSConstants.SYNCWRITE_DIRECTWRITE

Parameters:

policy - The new synchronousWritePolicy value

Throws:

javax.management.InvalidAttributeValueException -

DistributedManagementException -