<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept xml:lang="en" id="GUID-D541AD43-0832-57CB-BFB3-2FE386942F9B"><title>Handling of Multiple Clients</title><prolog><metadata><keywords/></metadata></prolog><conbody><section id="GUID-10385EFC-1D2E-5B5B-A45F-481DDB7FD7E6"><title>Overview</title> <p>The Contacts Model uses a Client Server architecture. Many clients can send requests to the server for operations on one or more contacts databases. </p> <p>In the case where multiple clients are accessing the same database the server will attempt to process the requests sequentially. </p> <p>Requests are usually carried out immediately: </p> <ul><li id="GUID-0C2B9C63-789B-5119-A184-EFEBB0D3C48B"><p>The request is valid for the current state and is processed </p> </li> <li id="GUID-CCDE2531-BC43-5611-AA73-DC6DF26AB938"><p>The request is not valid for the current state and is completed by leaving with an appropriate error code </p> </li> </ul> <p>There are however two scenarios where a request cannot be processed immediately: </p> <ul><li id="GUID-2FBB589B-0BB1-5BD9-AA34-81BEE3867A86"><p>The request needs to open or modify a contact item currently locked by any session </p> </li> <li id="GUID-8DA367AD-939A-58BF-887A-AADEFBCE33C4"><p>The current state of the server prevents the request from being carried out </p> </li> </ul> <p>In both of these cases the request is queued with the expectation that the condition preventing its completion will soon cease. </p> <p>When a contact item is unlocked, or the state of the server changes, an attempt is made to execute the first request in the queue. If the request still cannot be processed it is once again added to the queue. This activity is repeated for all queued requests. </p> <p>A request will only remain in the queue for a defined period known as the operation timeout. At the end of this period the client’s request will be completed by leaving with an error code appropriate for the request. These error codes conform to the values used in the previous version of the Contacts Model. </p> </section> <section id="GUID-92691A23-A7E9-5C54-A4BF-A84CE7358F65"><title>Setting the Operation Timeout Value</title> <p>The following API is used to set the operation timeout value: </p> <codeblock id="GUID-6E74B20E-5C63-5ADA-9AAB-459416A58DC7" xml:space="preserve">void CContactDatabase::SetOperationTimeOutL(const TInt aMilSeconds) const</codeblock> <table id="GUID-3C039DC6-75D0-5C60-965C-2312CB353DB6"><tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/><tbody><row><entry><p>Parameter </p> </entry> <entry><p> <i>aMilSeconds </i>  </p> <p>The operation timeout in milliseconds. This timeout is only applied to requests sent by clients of this database after this time. </p> </entry> </row> </tbody> </tgroup> </table> </section> <section id="GUID-4AAFE94A-183C-57D5-9456-09026F050DE7"><title>Implementation Considerations </title> <p>By default the operation timeout is 1 second. You may wish to change this value based on the way in which the application layer uses the Contacts Model. </p> <p>The timeout is set per session – multiple clients using the same database can specify independent values for the operation timeout. </p> </section> </conbody></concept>