Share via

2.3.1.1 CellSubRequestDataType

  • Article

The CellSubRequestDataType complex type contains information about data or input parameters used in processing a cell subrequest.

 <xs:complexType name="CellSubRequestDataType" mixed="true">
     <xs:all>
       <xs:element ref="i:Include" minOccurs="0" maxOccurs="1" />
     </xs:all>
     <xs:attributeGroup ref="tns:CellSubRequestDataOptionalAttributes" />
     <xs:attribute name="SchemaLockID" type="xs:string" use="optional" />
     <xs:attribute name="ExclusiveLockID" type="xs:string" use="optional"/>
     <xs:attribute name="Timeout" type="xs:integer" use="optional" />
     <xs:attribute name="BinaryDataSize" type="xs:long" use="required" /> 
 </xs:complexType>

Include: A complex type, as specified in [XOP10] section 2.1, that is used for encapsulating and sending large amounts of binary data. The referenced Include element is specified in section 2.2.3.1. The referenced Include element MUST be sent as part of the SubRequestData element in a cell storage service request message only if the cell subrequest is for the upload of a file’s binary or metadata contents.

CellSubRequestDataOptionalAttributes: An attribute group that specifies the set of attributes that is provided for a SubRequestData element whose parent SubRequest element’s Type attribute is set to "Cell". CellSubRequestDataOptionalAttributes is defined in section 2.3.3.1.

SchemaLockID: A string that is globally unique and known among all protocol clients that share the same protocol version. This schema lock identifier is used by the protocol server to block other clients with a different schema lock identifier, if the ByPassLockID is not set or not same with this schema lock identified, the SchemaLockID will be ignored by the server. After a protocol client is able to get a shared lock for a file with a specific schema lock identifier, the server MUST allow only other protocol clients that specify the same schema lock identifier to share the file lock. The protocol server ensures that at any instant in time, only clients having the same schema lock identifier can lock the file. After all the protocol clients have released their lock for that file, the protocol server MUST allow a protocol client with a different schema lock identifier to get a shared lock for that file. The SchemaLockID attribute MUST be specified in a cell subrequest if both of the following conditions are true:

  • The Coalesce attribute is set to true, and the protocol client holds a shared lock on the file. The Coalesce attribute is defined in section 2.3.3.1.

  • The cell subrequest is for uploading binary file contents in a partition.

The string "29358EC1-E813-4793-8E70-ED0344E7B73C" has been reserved for use for this attribute.<27>

ExclusiveLockID: A string that serves as a unique identifier for the type of exclusive lock on the file when a cell subrequest with the Coalesce attribute set to true is requested. The Coalesce attribute is defined in section 2.3.3.1. ExclusiveLockID is sent only if the protocol server supports file locking and the cell subrequest is for the first time upload of the file’s binary contents.

Timeout: An integer that specifies the time, in seconds, after which the exclusive lock on the file will expire. The Timeout attribute MUST be set to a value ranging from 60 through 120,000. The Timeout attribute MUST be specified if the ExclusiveLockID attribute is specified.

BinaryDataSize: A long value that specifies the number of bytes of data in the SubRequestData element of a cell subrequest. It MUST be present in the SubRequestData element of a cell subrequest. The BinaryDataSize attribute MUST be set to a value ranging from 1 through 9,223,372,036,854,775,807. It is ignored by the server. The SubRequestData element is defined in section 2.2.3.9.

If text is specified in the SubRequestData element, that text is base64 binary encoded data and indicates if the cell subrequest is for the upload or download of data in a partition. This is passed to the component on the protocol server responsible for implementing the protocols as specified in [MS-FSSHTTPB] section 3.1.4.2 and [MS-FSSHTTPB] section 3.1.4.3. The encoded data is opaque to the protocol.