If set to true, operations that modify the state managed by the DataService are committed immediately. If set to false, you must explicitly call the commit() method to send the changes to the server.

The default value is true.

When set to true, any changes made to a collection are committed immediately if the autoCommit property is true. When it is set to false, any add/remove operations you perform on a collection are not committed immediately.

The default value is true.

When set to true and the autoCommit property is set to true, any property value change automatically leads to a "commit" for that change. If false, changing the property on a VO will not automatically cause a commit call. To commit an update, you instead can call the commit() method explicitly, or you can call the DataManager.updateItem() method to commit changes to just that item.

The default value is true.

Indicates if this service should attempt to connect for any operations that require a connection. Operations such as fill(), getItem(), and count() attempt to connect if the service is disconnected and autoConnect is set to true. Use this property to control occasionally connected application behavior.

Time interval in milliseconds to wait between attempts to connect to the server when the autoConnect property is true.

The default value is 5000.

Controls how changes that other clients make are merged into this client's current view of the data. If this property is false, messages are queued up until the application invokes the merge() method explicitly. If this property is true, changes are applied as they come in. If the client has pending uncommitted changes made to an item that conflict with the merged changes, a conflict is generated and added to the list of unresolved conflicts for this client. You can listen for change events on this property to be notified when a merge needs to be applied.

The local cache of data and changes can be stored to disk. When autoSaveCache is true each time a change is made or a remote request is returned that data will be saved to disk. If there is a problem saving the data either because the disk is full or write permissions have been denied a FaultEvent will be dispatched or a Fault will be thrown. Setting this value to false (the default) will not save any data or changes to disk. To force the current data and changes to be saved locally use the saveCache method.

See also

Provides access to the cache identifier for this service. A cache identifier must be set prior to performing any operations that require interaction with data stored locally on disk. If a cache identifier is not set all cache methods and properties are considered inconsistent DataServiceError will be thrown during any operation that requires data from the local disk. This property is provides a unique "session" identifier for data stored locally. A developer must set this property to a unique value for the application. A value of null or empty string is considered unset.

Provides access to the ChannelSet used by the this DataStore. The ChannelSet can be manually constructed and assigned, or it will be dynamically created to use the configured Channels for the destinations using this DataStore. The channelSet should be the same for all DataService objects using the same DataStore.

Controls when a committed batch of changes is sent to the server when you call commit on a second batch while the client is still waiting for a reply from a previously committed batch. If the batch is immediately sent to the server, it can cause problems if changes in this batch are dependent upon changes made by the server when committing the previous batch. For example, you may be updating an item created by the server in the first batch. If the server assigned id has not yet been received by the client, the update will not include the proper id for that item. If the second batch always waits for the first batch to complete, it can increase the time it makes to perform a series of changes that are time dependent (e.g. if you are updating a cursor position over and over again).

The default mode is CQ_AUTO. This mode checks for simple dependencies between any outstanding batches and the next batch to commit. If it sees that there are none, it sends the new batch immediately. If it sees that it has an update or a delete which depend upon an outstanding create, it holds the update/delete until the create completes. This imposes some overhead on each commit to check for dependencies but is typically a good compromise between the other two modes, CQ_NOWAIT and CQ_ONE_AT_A_TIME.

CQ_NOWAIT will send the second batch immediately, not checking for dependencies. You might use this mode if you are assigning ids for new objects on the client and need to overlap batches to achieve performance goals.

CQ_ONE_AT_A_TIME will always wait for a previous batch to complete before committing a new batch. This mode simplifies error handling logic by ensuring the server will not receive a batch of changes missing changes made by the server in handling the previous batch. It also ensures that if an error occurs handling one batch that the server won't receive a second batch until the errors for the first one are resolved on the client.

The default value is CQ_AUTO.

Indicates if there are pending updates that must be committed.

This property can be used as the source for data binding. When this property is modified, it dispatches the propertyChange event.

The list of conflicts for all managed items.

This property can be used as the source for data binding. When this property is modified, it dispatches the propertyChange event.

Indicates whether the DataStore is connected.

This property can be used as the source for data binding. When this property is modified, it dispatches the propertyChange event.

The current batch of changes waiting to be committed to the server when you autoCommit=false. You can use this property to iterate through the changes that will be applied when you call the commit() method. A batch can be committed or reverted independently of the other batches. The entire set of uncommitted batches is stored in the uncommittedBatches property. The value of the currentBatch property is always the last batch in the uncommittedBatches list.

This property can be used as the source for data binding. When this property is modified, it dispatches the propertyChange event.

The destination for this DataStore.

A flag you can set to disable conflict detection during the refresh/reconnect operation. In LiveCycle Data Services version 2.6.1, conflict detection was not done on refresh so you can set this to false to restore the 2.6.1 behavior.

The default value is true.

The identifier of this DataStore. This optional property is used with cache configuration to uniquely identify this DataStore. This value must be session independent, that is, you should not create this identifier at runtime using a method like UIDUtil.createUID() If this value is not assigned one is calculated based on server configuration values for the associated channels.

Indicates when this DataStore is initialized and ready for use. This property is only needed when working with a runtime configured application or one that needs access to locally cached data on disk.

This property can be used as the source for data binding. When this property is modified, it dispatches the propertyChange event.

Indicates if there are any pending changes that must be merged.

This property can be used as the source for data binding. When this property is modified, it dispatches the propertyChange event.

The default message priority for the messages sent by the DataStore. The valid values are 0 to 9 (0 being lowest) and -1 means that the DataStore does not have a priority set. Note that if the message already has a priority defined, that takes precedence over this priority.

Indicates whether or not pushed server changes are currently being merged into the client's view of the managed objects. This happens at any time when autoMerge is true. If autoMerge is false, this will only be set when you are explictly calling the merge method. The point of this flag is to let you know the difference between an asynchronous server pushed changed and one made by the user in your set methods.

This property can be used as the source for data binding. When this property is modified, it dispatches the propertyChange event.

Provides access to the request timeout in seconds for an operation. A value less than or equal to zero prevents request timeout.

When the client receives an error processing a message, setting this property to true causes it to "uncommit" any batches which you've committed but have not yet been sent to the server. If you set the commitQueueMode property to ONE_AT_A_TIME and set this property to true, you can only deal with one batches errors at a time. Otherwise, it is possible to receive faults from a series of faults which can make resolving them a bit more complicated.

The default value is false.

This time interval can be set to reduce the frequency of how often the cache is saved. When the autoSaveCache property is true, LiveCycle Data Services saves the cache after each change. If you have a reasonable large cache, this can be expensive so you might want to reduce the frequency in which the cache is saved. If you set this property to 1000 milliseconds, the cache is saved no more than once per second.

The default value is 0.

A flag you can set to false to restore the LiveCycle Data Services 2.6 behavior of logging an error but not throwing an error when the UID property is changed.

The default value is true.

The list of MessageBatches which are currently uncommitted. To preserve data integrity, in general the order of operations should not be altered so this list is read-only. You create a new batch by calling the createBatch() method. This method adds a new batch to the end of the uncommittedBatches list and sets currentBatch to be the last element in that list.

These properties are bindable so you can watch for the commitRequired flag in a particular batch to see if it has changes, or bind against the items property to get the list of MessageCacheItems waiting to be committed as part of that batch.

This property can be used as the source for data binding. When this property is modified, it dispatches the propertyChange event.

Normally, a DataStore is created automatically for you but you can create your own DataStore and assign it to the dataStore property of a DataService. To do this, you must ensure all data services that share the same data store use the same channel set and have the same value of the use-transactions configuration setting. Use this constructor to create a DataStore where the destination parameter contains the destination of one of the DataServices using this data store. This is just used to look up the channel set. You also should provide the value for the use-transactions flag for this data store.

Commits pending changes for collections and items managed by this DataStore. When the autoCommit property is true, transactions are not used and you do not need to call this method. To use transactions, set the autoCommit property to false and call this method directly to commit a batch of changes. You typically just call "commit()" with no arguments which will commit all pending changes. You can supply optional arguments to commit a subset of the pending changes.

You must resolve all outstanding conflicts before you can commit changes to any item in the DataStore.

If the assembler is configured to have use-transactions set to true, all changes are committed atomically. If any operation fails, none of the operations in the batch are applied. If use-transactions is set to false, the operations are each committed individually until a failure occurs at which point processing stops. Any changes that occur before the error are applied, any changes which occur after the error are not applied. When an error occurs when processing a batch, the changes are put back into the uncommitted queue. You need to call revertChanges if you want to remove the changes which caused the error.

By default, the commit method will commit all pending changes for all items which have been created, modified, and deleted for this DataStore. If you want to commit a subset of these changes, you can specify a combination of managed ArrayCollection instances and/or managed items which define the subset of changes you want included in the batch. For each array collection you specify, any changes made either to the membership or order of items in that array collection or any changes to items in that array collection are committed. You can also specify a list of individual managed items so that only changes for those items are committed. If you specify any objects in the itemsOrCollections parameter which are not managed collections or items, a DataServiceError is thrown.

If you are using the itemsOrCollections parameter and your items have association properties which refer to other items, you can use the cascadeCommit parameter to control whether or not changes made to associated items are also included in batch. For example, if you specify a Group item in the items parameter, and the Group instance has a members property which refers to a list of Person instances when cascadeCommit is true changes to any Person instance will also be included in the set of changes committed. If cascadeCommit is false, only changes to the Group would be included. Use cascadeCommit=true to ensure that any dependent changes are included in the batch.

Parameters

Forces a connection attempt by this service to the remote destination. This method may be used in conjunction with the autoConnect property and disconnect() method to control connection status.

Takes any changes specified by this operation, creates a new MessageBatch and puts that batch into the uncommittedBatches list. If itemsOrCollection=null, the entire set of messages in the currentBatch are put into the new batch and a new batch is created as the currentBatch. You call this method when you want to partition a set of changes to mark a block of work that can be committed or reverted as a unit. For example, if you create a parent object and create a child which is associated with that parent, I might then call 'createBatch()' to put both of these changes into a group. If you do this twice, you'd have two batches each creating one parent and one child. You can then commit each group of changes independently as long as they are committed in the order in which the batches were created. You also could revert the most recent batch and it would leave the first batch unchanged. A simple multi-level"undo" system can be implemented this way simply by calling createBatch(null) after each operation.

You can mark a batch with a set of user-defined properties with the MessageBatch.properties property (or the properties argument to this method). This information gets saved and restored with the batch when using the offline feature and can be used to identify the batch on the client. Values placed in here must be serializable (i.e. Objects or classes with [RemoteClass]).

If you supply a value for the itemsOrCollection parameter, a new batch is created which just has the changes for the item or collection of items. If you set cascadeCommit to true, any changes for associated items are also included in the set of messages split out into the new batch.

Parameters

Forces all data services using this data store to be disconnected.

This method will fill the specified ListCollectionView with all cache identifiers previously used in the application.

Parameters

Log the user out from the current destination. Calling this method will log out all associated DataService instances.

Merges any pending updates into the managed set of objects. The process of merging changes can detect conflicts.

Refetch all data managed on the client.

Release all data managed on the client. This will free up the item and query caches on the client for all data as well as unsubscribing from any auto-sync'd data on the server.

Parameters

Reverts all pending (uncommitted) changes for all DataServices managed by this DataStore.

Reverts all pending (uncommitted) changes for any items in the specified managed collection.

Parameters

Set the credentials for this DataStore destination.

Parameters

Set the credentials for the 3rd party of this DataStore destination.

Parameters

Dispatched when a conflict is detected between either pending changes on this client and changes submitted by another client, or when changes submitted by this client result detect a conflict error at the remote destination. The DataStore dispatches conflict events for all destinations which share the DataStore, or you can listen for conflict events for a specific type on a DataService. Use the DataStore when you have an object with associations as in that case, you may need to resolve conflicts in a specific order to maintain integrity of those associations.

The properties of the event object have the following values:

The FaultEvent.FAULT event is dispatched when the commit call returns an error.

The properties of the event object have the following values:

The ResultEvent.RESULT event is dispatched when the commit call successfully returns.

The properties of the event object have the following values:

Specifies to check for simple dependencies between any outstanding batches and the next batch to commit.

Specifies to send the second batch immediately, not checking for dependencies.

Specifies to wait for a previous batch to complete before committing a new batch.