Analyzing Performance of Lease-Based Schemes and

Predicting Lease Duration for Object Systems

Roman VitenbergDepartment of InformaticsUniversity of Oslo, Norway

romanvi@ifi.uio.no

Dmitry ZinenkoIsrael Institute of Technology

Haifa, Israeldelta@cs.technion.ac.il

Kristian KvilekvalDepartment of Computer Science

University of California, Santa Barbarakris@cs.ucsb.edu

Ambuj SinghDepartment of Computer Science

University of California, Santa Barbaraambuj@cs.ucsb.edu

Abstract

Leases have proved to be an effective concurrency control technique for distributed systems thatare prone to failures. However, many benefits of leases are only realized when leases are granted forapproximately the time of expected use. Correct assessment of lease duration has proven difficult for allbut the simplest of resource allocation problems.

In this paper, we present a model that captures a number of different lease styles and semanticsused in practice. We consider a few performance characteristics for lease-based systems and analyticallyderive how they are affected by lease duration. We also introduce a novel automatic method of leasecalculation for complex transactions on object systems based on program analysis. We confirm ouranalytical findings, complement them, and demonstrate the prediction technique by running a set ofexperiments with the OO7 benchmark suite using a variety of workloads and faultloads.

1 Introduction

Leasing [9] has become a popular model for resource sharing control when communication failures are frequentor when clients cannot be trusted to securely release resources in a timely fashion. A lease is a temporarycontract between the client (lessee) and the server (lessor) that binds the server to make resources accessibleto the client and provide certain services (such as sending updates or notifications) during the time of a lease.Leases permit servers to provide consistent access to resources and data and make guaranteed progress evenin the presence of failures.

However, in order to use leases effectively, a program designer should be able to estimate the requiredlease duration. Short leases permit the resource to recover quickly in the case of a client failure, but increasethe message load for both clients and servers. Long leases require less renewal traffic, but suffer the sameresponsiveness problems as locks. In order to attain the optimum balance between robustness and resourceuse for any application, a program or system designer should make lease duration adaptive. In particular, thisduration should match the time for which the client requires the resource or service. Yet, most lease-basedsystems commonly employed in practice simply fix the lease duration to some configurable value.

The main contribution of this paper is a new analytical model for lease-based systems, which allows usto evaluate the effect of lease duration on the performance. Our analysis includes a number of performancecharacteristics pertaining to lease efficiency: wait duration for the client before the lease is granted, totallease ownership time Tlo, wasted lease ownership Twlo when the resource or service is no longer needed by theclient, lease inefficiency Twlo/Tlo, and the number of lease requests sent per lease. The model captures both

1

fixed-time leases and adaptive schemes. It distinguishes between two lease styles. Lock-style (LS) leases areused as time-limited locks and guard an exclusive access to resource. Service-provision (SP) leases entitlethe client to receiving time-limited services from the server, such as data storage and caching or update andnotification delivery. Typically, the same lessor is able to provide services to multiple clients in parallel, sothat an SP lease is not exclusive.

We consider a number of failure types in the analysis. Normally, the client relinquishes the lease that isno longer needed. Software bugs may, however, cause the client to continue holding the lease in this casethereby reducing the overall efficiency of a lease-based scheme. Client crashes and message omissions maylead to a similar result. Additionally, they may affect the degree of contention for LS leases. Our modelexamines the effect of these failure types separately and in combination with each other.

The other contribution of this work is a method of automatic lease estimation for object-based systems.Our technique uses program analysis in order to create a summary of the code executed during a transaction.Our program analysis creates a modified shape-graph [10] which can be used as a summary of the program’sactions. We annotate the shape graphs with instruction costs related to the summarized program fragments.Program summary information is combined with actual database data at runtime to determine the expectedlength of the required lease.

In the most general case, the problem of execution time prediction is equivalent to the halting problem,which is undecidable. For example, when the number of conditional branches in the program fragment thatdeals with resources is high, our technique will not be able to help. However, the program analysis we deployis able to determine when the program is mostly deterministic and compute expected lease duration only inthose cases.

We have created a benchmark testbed in order to verify our analytical findings and test the predictiontechnique. We run experiments with the standard OO7 benchmark suite that has been augmented withour implementation of the lease manager. The experiments use different failure models and failure rates aswell as a variety of workloads with different operation durations and request rates. The obtained resultssuggest a number of interesting conclusions wrt, e.g., the lease duration tradeoff and potential of the pre-diction methodology. The experimental findings also illustrate some dependencies that we have not derivedanalytically, for example, how contention and wait duration for LS leases depend on lease duration.

2 Related work

While presumably used in early software systems, leases were introduced as a stand-alone technique in [9]for dealing with cache consistency in a distributed file system. In general, the lease technique can be seen asa contract between two software entities, one of which is bound to provide services to the other during thelease duration. Here are several typical uses of leases:

• In many cases, a resource is shared across several distributed entities and this resource must be exclu-sively owned by an entity in order to perform some operation. If either the entities or the network throughwhich they communicate are prone to failures, it may happen that the ownership over the resource is neverreleased. Leases can be used in order to implement resource allocation that is resilient to such failures. Inparticular, leases are typically used in file systems that support disconnected operation [12,15] or in mobiledatabases [11] or in commercial database implementations, e.g., by IBM, Microsoft, Oracle or Sybase. Otherexamples include IP address allocation by the DHCP protocol and service allocation in Jini [17].

• Other distributed services allocate resources that are not shared, or for which resource ownership isnot exclusive. For example, caching services or advertisement services like yellow pages may store client dataor objects for a certain period of time. The reason to use leases in such applications is reduced update costs,or in order to prevent the accumulation of outdated unused records.

• Leases can be part of the mechanism for maintaining consistency between primary and backup datacopies. All updates to the data are pushed from the primary to backups during the lease duration. Such ascheme is employed, e.g., maintaining consistency of Web documents [5, 20]. Similarly, in publish-subscribeinformation dissemination systems, a lease signifies the period during which the service is bound to deliverinformation to subscribers.

2

[8] studies the impact of lease duration on the performance of lease schemes for proxy-server http-basedcommunication in the Web application. This work assumes a failure-free environment wherein the drawbackof long leases is not reduced responsiveness but increased space allocation at the server, which may behandling a huge number of concurrent requests. In contrast, we focus on the effect of failures for a widervariety of lease applications.

There is a significant body of research in the area of dependability analysis, as presented, e.g., in [18].The methodology has not been applied to lease-based schemes despite their common use, to the best of ourknowledge.

Our past publications show how to exploit shape analysis for object prefetching [13] and improved lockscheduling [19]. This work is the first to use shape analysis for predicting lease duration.

3 Leases: benefits of use and challenges of implementation

In most lease-based schemes, leases fulfill either or both of the following two roles: a) time-limited locks forproviding concurrent control to resources and b) time-limited agreement of providing/consuming a service,such as propagating updates on the cached data between a Web server and proxies. We will now considerthe shared characteristics of these two schemes while leaving the differences to the specific scheme analysisin Sections 5.3 and 5.2.

The main motivation behind using timed leases is to achieve resilience to site and network failures: if thelessee crashes or detaches from the rest of the system, the resource it is holding will be revoked and the systemwill remain operational. The standard API of leases includes acquire, renew and release primitives forattaining, extending, and relinquishing the lease, respectively. The duration of a lease is determined uponcalling acquire, either by the requester or by the authority that grants the lease (lessor). Once the leaseis expired, the lessor revokes the lease regardless of whether the resource is still required by the lessee. Inorder to proceed working with the resource beyond the initial lease duration, the lessee must issue a renewrequest, which resets the timer on the lessor to the specified duration. Finally, some lease-based systemsprovide the lessee with ability to explicitly relinquish the lease by calling release. This is useful when thelessee finishes working with the resource before the timeout expires and is able to release it ahead of time.

This paper focuses on the main challenge of dealing with leases: determining the optimal lease duration.The duration of a lease exhibits a well-known tradeoff: shorter leases require sending unnecessary renewrequests while longer leases render the system less adaptive to failures. Furthermore, long lease durationslead to false resource sharing when the system does not provide release primitive. False resource sharingis a situation when a lessee L holds a lease on a resource that L does not need any longer. False sharingmay also arise when the lessee forgets to invoke release, e.g., because of a software error.

Despite individual studies of adaptive lease schemes in the Web environment (e.g., in [8]), most existingsystems simply fix the lease duration to some configurable value. While this policy may be sufficient forsimple resource requests, multi-lease operations require a more exact lease determination in order to remainefficient. This work aims at quantifying the above tradeoff and analyzing the gain in performance when leaseduration is assessed correctly.

4 System Model

We assume that the system consists of a number of nodes communicating by message passing. Each nodeis assigned a fixed role of either lessee or a lessor; mixed schemes with interdependencies where a lease isgranted only if the lessor holds another lease are beyond the scope of this paper.

Our formal treatment assumes fully synchronous model with negligible request processing overhead anddelivery latency of both request and reply messages. This assumption is justified by the fact that a typicallease duration is much longer than relative clock drift, request processing overhead, and delivery latency inmost practical systems. Our experimental analysis in Section 8 confirms that those factors have little impacton the results apart from few specific cases that we explain in that section.

3

time

�� ����� �� �������� ������Figure 1: Operational phases of a lease ownership cycle

Lease-based systems have been conceptually conceived to tolerate link and lessee failures, which are thetypes of failures considered in this work. Section 5.1 conducts performance analysis for a more specific failuremodel.

5 Analytical Model for Leases

Figure 1 depicts the phases of a lease ownership cycle. tR denotes the time when the acquire request isissued. The request is never denied but it may be blocked in the case of a contention over an exclusivelyowned resource (the wait duration is denoted by Twait). Once the wait is over, the lease is granted for theduration of Tl. If necessary, the lessee may renew the lease as many times as needed. A renew request isalways immediately satisfied (we do not consider preemptive leases) thereby granting an additional Tl period.Tl may vary for different lessees and even for different acquire requests of the same lessee. This modelcaptures both fixed-time leases and schemes where the system attempts to predict correct lease duration. Itis our intention to consider the effect of different choices for Tl in various models.

Let us denote the total time during which the resource or service is indeed needed by Tr. If Tr is knownto or can be predicted by the system, the system may take advantage of it and set Tl accordingly.

We analyze the effect of both false sharing and failures on the performance by considering systems of fourtypes: a) S-NF systems that allow false sharing (release is never used) but not failures, b) NS-F systemsthat allow failures but not false sharing (release is always used), c) S-F systems that allow both, and d)NS-NF systems that allow neither.

We now consider the impact of Tr, Tl, and specific lease model and type on the following characteristics oflease performance: Twait, lease ownership time Tlo, useful lease ownership time Tulo, wasted lease ownershiptime Twlo, lease system inefficiency LI, and the number of renew requests sent per lease. Lease ownershiptime is the total period of time over which a lease was granted including all renewals. In the case of a failure,Tlo includes the period of time after the failure and until the lease is relinquished.

Tlo consists of two intervals: useful and wasted lease ownership time. Useful lease ownership is the timewhen the resource or service is used by the client. Wasted lease ownership is the remainder of Tlo that mayexist because of a failure or false sharing. Tulo = Tlo = Tr in the NS-NF model. Tulo = Tr ≤ Tlo in the S-NFmodel. Tulo ≤ Tr in the NS-F and S-F models. Twlo ≤ Tl in all the models. Lease system inefficiency LI isdefined as Twlo/Tlo. Intuitively, LI represents the percentage of the lease ownership time that is wasted.

Table 1 summarizes the notation we are using for the model. In particular, we will use the shortcutnotation of Tm to denote dTr/TleTl in the rest of the paper.

The exact effect of wasted lease ownership is different for different types of leases and considered inSections 5.3 and 5.2 but it is always undesirable. A lease-based scheme should strive to minimize Twlo andTwait relative to Tulo while keeping the number of renew requests low.

4

Table 1: Notation summaryNotation Brief explanationTl Lease request timeTr Duration for which the resource is requiredTm dTr/TleTl

Tu Mean time between updates for service leasestR The time of request arrival

ResultsTwait Blocking time due to contentionTlo Total lease time of requestTwlo Wasted lease timeTulo Useful lease timeLI Lease system inefficiency

5.1 Performance of a lease-based scheme as a function of Tr, Tl, and lease type

It is known that the degree of contention in a lock-based scheme depends on a lot of factors. In particular,Twait for a particular acquire request may depend on the schedule of all other concurrent requests. Onthe other hand, if we assume that Tr is independent of contention (which implies in particular, that thelessee does not issue acquire request for another lease in the middle of a lease ownership period), thenTulo and Twlo depend only on Tr, Tl, lease type, and failures in the middle of the lease ownership period.This observation allows us to analyze the performance of a given lease ownership separately from other leaserequests by the same or other lessees.

We now derive Tulo, Twlo, LI, and the number of renew requests as functions of Tr and Tl for NS-NF,S-NF, NS-F, and S-F models. For NS-F and S-F models, we consider a more specific failure model: failuresare distributed exponentially with the rate parameter λ. Because of the above observation and the fact thatan exponential distribution is memoryless, failures occurring in the middle of a lease ownership period onlyaffect this lease ownership (apart from potentially affecting Twait for other lease requests). Furthermore,recoveries may have effect only on Twait through their impact on contention; they do not affect any othercharacteristics. Therefore, we will limit the discussion of recovery time distribution to those parts of theanalysis and evaluation where contention becomes relevant.

For each of the above characteristics, we are interested in the minimal, maximal, and average values foreach of the NS-NF, S-NF, NS-F, and S-F models. For NS-F and S-F, the average is taken over x, which isthe time of failure, for given values of Tr, Tl, and λ.

We show the technical details of the derivations in Appendix A. Our results are summarized in Tables 2,3, 4, and 5 and Equations 1, 2, and 3 where we use the shortcut notation of

γ = Tl(1− e

−λTlbTrTlc

1− e−λTl+ e

−λbTrTlcTl − (bTr

Tlc+ 1)e−λTr ) and γ′ =

1λ

(e−λTr (−λTr − 1) + 1).

TwloS-F

= γ − γ′ + (Tm − Tr)e−λTr . (1)

LINS-F

= (2)

= e−λTlbTr

Tlc − e−λTr +

1 + eλTl(λTl − 1)λTl

bTrTlc∑

a=1

e−λaTl

a−

− 1dTr

TleλTl

(e−λTr (−λTr − 1)− e−λbTr

TlcTl(−λbTr

TlcTl − 1)).

LIS-F

= LINS-F

+Tm − Tr

Tme−λTr . (3)

5

Table 2: Results for NS-NFParam Min Max AvgTlo Tr Tr Tr

Twlo 0 0 0LI 0 0 0

Table 3: Results for S-NFParam Min Max AvgTlo Tm Tm Tm

Twlo Tm − Tr Tm − Tr Tm − Tr

LI 1− Tr/Tm 1− Tr/Tm 1− Tr/Tm

Table 4: Results for NS-FParam Min Max AvgTlo min(Tl, Tr) Tm γ + Tre

−λTr

Twlo 0 Tl γ − γ′

LI 0 1 Equation 2

Table 5: Results for S-FParam Min Max AvgTlo Tl Tm γ + Tme−λTr

Twlo max(0, Tl − Tr) Tl Equation 1LI max(0, 1− Tr/Tl) 1 Equation 3

There is an additional important characteristic not represented in the tables, namely, the number ofmessages sent in a lease-based system: a lessee always sends a single acquire request. It sends one releaserequest in NS-F and NS-NF systems and no release requests in S-F and S-NF systems. The number ofrenew requests will always be dTlo/Tle− 1 in any system. Obviously, from the standpoint of renew requests,the optimal Tl is equal to or greater than Tr. The total number of request messages (one acquire and allrenew requests) can be expressed as follows: dTr/Tle both for NS-NF and S-NF systems. For NS-F andS-F systems, it is γ

Tl+ dTr

Tlee−λTr .

Later in Section 8, we reflect on our analytical findings when contrasting them against the results of ourexperiments. In particular, the analytical findings have the following practical applications:

• They quantity the tradeoff between short and long leases and aid the system designer in treading thebalance between them.

• They quantify the potential performance gain by prediction techniques of Section 6.• They give insight about the non-trivial interference of failures of different types. Notably, the combi-

nation of false sharing with failures may lead to non-trivial consequences: the average Twlo is always biggerfor an S-F system than for an NS-F system. However, the comparison between S-NF and both models withfailures is more interesting: if Tr mod Tl is close to 0, then Twlo is bigger for an S-NF system than for anS-F system. In other words, failures may reduce the average performance penalty incurred by false sharing.If Tr mod Tl is close to Tl, then the opposite is true. If Tr mod Tl is close to 0, then the comparison betweenS-NF and NS-F systems further depends on λ.

• They provide insight about the effect of failure rates on lease performance.Experimental analysis extends these applications, e.g., by providing an insight about variability of per-

formance characteristics.

5.2 Service provision (SP) leases

In this style of leases, the holder of a lease is entitled to receiving a priori services from the lessor for the leaseduration. Typically, the same lessor is able to provide services to multiple clients at the same time, so that

6

an SP lease is not exclusive. While multiple clients may be contending for access to the lessor, the pendingtime Twait due to contention is typically negligible compared with Tr under the assumption that the lessorcapacity is adequate for the load. For example, consider the common service of updating cached data thatis held by the client (i.e., fetching a copy of the data from the lessor upon acquire and receiving push-styleupdates for the lease duration). Contention may lead to a delay of a few milliseconds in this applicationwhereas the common lease duration is in the order of dozens of seconds or a few minutes.

The effect of wasted lease ownership for SP leases is providing the unnecessary service for Twlo. Considerthe aforementioned service of updating cached data. Let us denote the average time between two consecutivedata updates by Tu. Then, dTlo/Tue update messages are sent per lease in a system of any type for given λ,Tr, Tl, tR, and Tu. Out of those, about Twlo/Tu are wasted. LI roughly represents the percentage of wastedmessages.

Let us consider the average of dTlo/Tue: it is dTr/Tue for an NS-NF system and d Tl

TudTr

Tlee for an S-NF

system. For NS-F and S-F systems, it is∫∞0dTlo(x)

Tuepdf(x)dx.

5.3 Lock-style (LS) leases

The other most common use of leases is for managing concurrent accesses to shared resources or data. Whilethe lease is in force, the client will have exclusive access to the resource. This style of leases is often usedin distributed applications where strict consistency is desired and where the workload is characterized by ahigh degree of contention, for example, in distributed database systems. Another example of this style wouldbe DHCP where only one client may be assigned the resource (an IP address) at a time.

The lease model in Section 5.1 also captures this lease style. However, unlike SP leases, LS leases createcontention for shared resources so that an acquire request may be not granted immediately and Twait maybe non-zero. The main negative effect of wasted lease ownership is that it may increase Twait for other leaseacquisition requests in presence of contention. The extent of this effect depends on the degree of contentionin the workload, the details of the locking and scheduling mechanisms, and a lot of other factors hencemaking the analysis difficult. Our experiments presented in Section 8 explore the correlation between Twlo

and Twait for specific settings. Wasted lease ownership may also have a secondary negative effect for LSleases: the lessor may need to allocate resources to keep a track of lease ownership for the entire duration oflease ownership including the wasted part.

As shown in Section 5.1, failures in NS-F and S-F models may extend wasted lease ownership. It shouldbe noted that they have an additional negative impact for LS leases: if a failure occurs in the middle of atransaction, then the portion of the transaction that precedes the failure is wasted and the transaction mayhave to be restarted upon recovery.

Both LS and SP leases may be employed together in the same system. For example, in a mobile systemswith a stationary database server and mobile clients, a client that needs to update a data unit may acquirean LS lease from the server while all clients that need to read this data unit may acquire an SP lease.

6 Estimation of lease time

6.1 Overview

In order to predict, we must be able to guess the future actions of a program. Shape graphs capture theway in which the program’s code accesses data, allowing us to follow the same data paths that the originalprogram would take in order to access the data. This technique effectively predicts future data accesses ofthe program. We cannot follow the exact path, as most code has data-dependent branches. However, we cancapture a unified view of all program paths in the program’s shape graph. While this results in a necessarilyconservative estimation, it is incomparably smaller than the entire database, which can be exploited to deviseefficient predictors. Construction of shape graphs is given in more detail in Section 6.2.

In order to understand what a shape graph is, we present a typical program fragment of integrateddatabases in Figure 2. The shape graph shown on the right of the figure represents the code lines on the

7

class Connector{Part partA , PartB ; . . . }class Part {

Connector l e f t , r i ght , up , down ;Mater ia l mate r i a l ;Supp l i e r s upp l i e r ;Cost co s t ;. . .int volume ( ) ; }

1 : weight = 0 ;2 : while ( part != null )3 : weight += part . mate r i a l . dens i ty4 : ∗ part . volume ( ) ;5 : connector = part . r i g h t ;6 : part = null ;7 : i f ( connector != null )8 : part = connector . partB ;

AL

material

partB

rightpart connector

Figure 2: Code and shape: only items used in code (part,material) are in the shape graph.

left. It navigates the database in order to weigh the elements. While the database may be large and havea very rich object structure, many programs may use only part of that structure. The example code usesonly the material, and right fields of each part in the database ignoring the cost and supplier amongother fields. The access pattern is also revealed in the fact that the code fragment iterates through a listof part using the right field. In the graph, the node (part) is used to represent the values of the variablepart which access connector through the field right. The runtime value part.material is shown in theshape graph as AL. The cycle part through the field right to connector through partB and back to partcontains the needed loop information from the original code. In order to be completed, the volume methodwould need to be analyzed and merged with the shown shape.

Our prediction method uses the program’s access pattern represented by the shape graph and the actualobject graph contained in the OODB to generate the set of objects most likely to be used during thetransaction. Our runtime module visits the actual object structure guided by the references recorded in theprogram’s shape graphs.

6.2 Compile-time construction

The variant of shape analysis that we are using is a whole-program, flow-insensitive, context sensitive dataflow analysis and it is similar in design to those presented in [4,13,16,19]. Previously shape analysis has beenused to determine static properties of programs that manipulate heap data structures. We have extendedthis work to be used with OODB and combined the shape graphs in novel ways with runtime data.

Shape graphs are created and extended by simulating the actions of the program through abstractinterpretation, which creates and connects abstract heap tuples. Simple program actions, such as a fieldaccess instruction, create heap tuples. When two variables are determined to point to the same abstractlocation, we unify their heap representations. Unification is a recursive operation that begins with unifyingthe abstract locations and continues by unifying the compatible heap tuples that stem from the originallyunified location. Heap tuples are compatible when two abstract location have similarly labelled incomingshape edges. Given two abstract locations, that are to be unified, we first unify their abstract locations andthen recursively unify their compatible tuples in the heap.

The construction of the shape graph in Figure 2 begins as follows. The reference to the part in line2 creates an abstract variable in the symbolic interpretation of the program. Line 3 creates the link fromthe part abstract location to some unspecified location (AL) when the field is accessed. Similarly, line 5creates both the abstract location connector and the edge right between them when interpreted. Finally,

8

in line 7 the edge partB is created due to the field access and the resulting abstract location is unified tothe original part because of the assignment. Line 4 contains a call to a sub-method. The analysis of thesub-method would be similar to the one described above. After both methods have been analyzed, the localparameters passed to the method are unified with the formal parameters by the process described below.Program actions causing unification are summarized in Tab. 6.

Method calls are combined in a bottom-to-top fashion. The static call-graph is used to drive the entireinterprocedural analysis. The call-graph is partitioned into strongly connected components (SCC), thentopologically sorted. The method contexts (locals, globals, return value, and exceptions) for each method arepropagated bottom-up through all possible call sites. The shape graphs are propagated from callee to callerduring this phase through the unification of shape graphs. This allows the analysis to be context-sensitiveas the caller’s shape information is not mixed into callee. We lose this sensitivity for methods belonging tothe same SCC (mutually recursive methods) as all methods will share a single shape context [16]. In manycases the actual method receiver cannot be determined at compile time and this is a cause of uncertaintyin the graph. Rapid Type Analysis [2] is applied to each call site in order to reduce the number of possibletargets for each call site. For each target, the actual parameters are unified with a copy of callee methodcontext in the caller’s method context. As an example, the method call part.volume() in line 4 of fig. 2generates a sub-shape graph based on the type of part at runtime. This sub-shape graph is merged into thecaller’s context at the call point. Since we cannot determine at compile time which runtime type part willhave, we must unify all shape graphs from the target set.

Table 6: Statements causing unification of shape graphs and their effect. The fields array, formal and returnare special fields for array reference, method local and return values respectively.

Statement Abstract Location Descriptionx = y unify(AL(x), AL(y)) Assignmentx.field=y, y=x.field unify(AL(x).field, AL(y)) Field assignmentx = a[i], a[i] = x unify(AL(x), AL(a).array) Array assignmentreturn x unify(AL(x), AL(m).return) Function returnv = f(a1, ..., an) ∀t∈target(f)unify(AL(ai), AL(t).formal(i)) Invocation

∀t∈target(f)unify(AL(v), AL(t).return)x = new T AL(x) = ∅ Allocation

The specific construction mechanism is mostly identical to that we used in [19]. The special techniquewe implement for lease time prediction is to label each shape edge with the count of the first and lastaccess instruction. This value is calculated by examining the basic blocks of the transaction and findingthe minimum/maximum number of the instructions over all paths needed to access some abstract location.These values are used to determine the object access order and assist in determining the expected executiontime as explained in the following section.

The analysis creates shape graphs for the entire program. However, we need to store only those shapesthat will be useful at runtime. At a minimum, we must store an entire graph for each variable at the toplevel of the transaction. Further graphs may be stored depending on how often the predictive process willbe used during the transaction. We use the term granularity to specify the unit of work for the predictiveprocess. Transactions with coarse granularity will predict only once before the beginning of the transaction,while transactions with fine granularity will continuously refine their predictions by re-running the predictiveprocess. These issues are also discussed in Section 6.3.

The shape graphs themselves may be stored either on the client or on the database server. The shapegraphs are quite small (usually no more than several hundred nodes per transaction) and need to be com-municated at most once during the entire client session.

9

6.3 Runtime use

The runtime system can be triggered in a variety of ways to perform the actual prediction: either throughprogrammer annotations or through automatic identification and instrumentation of transaction routines.

Upon entrance, the runtime interprets the pre-computed shape graph over the actual program datagenerating the set of objects used by program. The runtime algorithm produces the future accessed objectsbased on the shapes extracted from the program. Along with each object to be accessed it also produceswhether the object can be the target of a write operation, the expected order in which the objects will beaccessed and finally the time the algorithm needs to compute while accessing the objects.

Before a transaction starts, we can follow the associated shape graph to generate an unordered set ofthe possibly accessed objects in the database. Given a transaction root object and the program point’sassociated shape graph, we generate all actual objects that might be accessed during the transaction. Eachshape graph represents how the transaction will manipulate structures referred to in the future by its visiblereferences (the object, arguments, globals) in the transaction body.

In our system, the middleware is responsible for interpreting the shape graphs of the client. Uponreceiving a transaction request, the server will walk the shape graph with a real object database object.This effectively simulates all possible program paths taken during the transaction over the database. Ourpseudo-code for walking the object graph is shown in Figure 3. The algorithm traverses the object graphbased on program’s field accesses represented by the shape graph. We search through the object graph ina breadth-first manner based on earliest expected access through the field. The server’s cost of predictionequals the cost of interpreting the shape graph over the input object graph.

The prediction walk is usually only done at the beginning of the transaction. However, the runtimesystem is capable of re-running the walk if further precision is desired and the associated shape graphs areavailable as discussed in Section 6.2.

// Input : An i n i t i a l o b j e c t o// A shape graph sg )// Return : A s e t o f accessed o b j e c t sL i s t DetermineObjects ( Object o , ShapeGraph sg )Queue<Object , Node> searchSet<Object> ob j e c t sSet<Object , Node> seensearch . push ( [ o , root ( sg ) ] )while not empty search

[ o , rv ] = search . pop ( )i f [ o , rv ] not in seen

seen . add ( [ o , rv ] )for each edge e in adjacent edges o f rv

next = read f i e l d e . f i e l d o f ob j e c t osearch . push ( [ next , rv . e ] )ob j e c t s . add ( next )

return ob j e c t s

Figure 3: Algorithm to determine objects using shape graph and object graph

For example, Fig. 4 has a shape graph with each abstract location node labelled with the count of theearliest access instruction. On the right, we show a database object graph. The database objects (o1..o6)have been labelled with their expected access time. In the example, Object o5 was reachable both throughNNJ with an instruction count of 20, or simply NJ with a count of 15. Note that it is possible that two objectsmay have the same first access time. This occurs when a data dependent branch in the program code ismerged together in the shape graph.

We measure the instructions contained in the basic-blocks creating the longest path between field accesses.By estimating the instruction time for these instruction sequences, we can arrive at an expected time ofcomputation between accesses. The object finding algorithm is modified to keep track of the maximumnumber of instructions to be executed during the navigation of the data structure. After visiting the data

10

G:5 K:10

F:10J:10

N:5a1

a2

a3

a4

a5

N N

F J J

K

o1:0 o6:10

o2:10 o5:15

o4:5

o3:20

Figure 4: Shape graph and object graph : Objects are linked through fields and have been labelled withexpected access time using shape graph.

structure guided by the shape graph, we estimate the number of instructions to completely execute thetransaction. This technique gives a conservative measure of the total time needed to execute the transactionby summing over all program paths. Currently we model only execution time and do not take into accountI/O costs. We believe this is not too strict a limitation, as in this case our target platform will have gatheredthe expected objects into local memory.

7 Experimental setup

Several standard benchmark sets for object-oriented databases, such as OO1 [7], and OO7 [6], have beendesigned to facilitate the testing of experimental database design techniques in realistic settings. We optedto conduct our experiments with the OO7 benchmark since it is the most complex in terms of the databasestructure and supported operation set. Additionally, the OO7 benchmark exhibits a rich object structure thatlends itself well to program shape analysis. Since the original OO7 benchmark were written in C++ whileour shape analysis implementation works for Java, we extended a Java port of the OO7 benchmarks [14]. Weextended the benchmark to be a multiuser version of the OO7 benchmark so that clients may concurrentlywork upon a shared database.

We summarize those details of the OO7 database description in [6] that are relevant to our experiments.The benchmark models a database for CAD/CAM/CASE applications. A key component of the databaseis a set of composite parts. Each composite part corresponds to a design primitive such as a register cell in aVLSI CAD application. At a lower level, each composite part has an associated graph of atomic parts. Wedo not access those atomic parts in our variant of the benchmark.

Composite parts are grouped into base assemblies.1 For example, in a VLSI CAD application, an assemblymight correspond to the design for a register file or an ALU. Base assemblies are further grouped into complexassemblies, which can be part of upper level complex assemblies. Cycles between assemblies are not allowed.Therefore, the overall organization can be visualized as a set of assembly hierarchies, each hierarchy beingcalled a module.

Figure 5 depicts the full structure of an OO7 module. The hierarchy scale is configurable with respectto several parameters. In our experiments, we worked with a single module because all operations providedby the benchmarks act on a single module so that having multiple modules does not create any interestingconcurrency issues. Other relevant parameters are the number of composite parts per module, the numberof composite parts per base assembly, the number of levels in the assembly hierarchy, and the number ofchild assemblies per complex assembly. Since the contention is only important for LS leases and the effectof database configuration on contention was not the main focus of our analysis, we used the same database

1Some parts may be shared across multiple assemblies while other parts may belong to a single assembly.

11

Figure 5: OO7 module [6]

configuration presented in Table 7 in all our experiments.

Table 7: OO7 database configuration# composite parts per module 50# composite parts per base assembly 27# levels in the hierarchy 3# assemblies per complex assembly 2

Table 8: Transaction typeTransaction Avg. Time PatternRead 2s single lease/lockUpdate 3s 2 nested leases/locksReorg 20s 2 nested leases/locks

Table 9: Workload and faultloadfailed operations 0%, 2.5%, 5%MTTF=1/λ, s ∞, 180, 90MTTR, s 5Request rate, op/s 0.2=1/5, 0.05=1/20, 0.025=1/40Op types Read 60%, Upd 30%, Reorg 10%

It should be noted that the web systems will often have a similar structure with top-level pages pointingto sub-pages and sub-pages connected into groups. We believe that our model is general enough to serve asexample for both typical OODBS and web systems.

In order to test the performance of lease-based schemes, we have augmented the OO7 suite with animplementation of a lease manager. The implementation includes both LS and SP lease styles and supportsboth fixed-duration and predictive leases.

Our simulation testbed is designed to explore how lease performance changes depending on the leaseduration Tl relative to Tr under a variety of workloads and faultloads. The testbed includes a) a syntheticworkload generator that produces a sequence of operations to be invoked at certain times along with theparameters to be passed to those operations and b) an artificial client that replays a previously generatedsequence of operations.

The testbed uses the following three operations of the OO7 suite: short reads, short writes, and longreorganizations as summarized in Table 8. The workload includes a mix of read and update operations, witha smaller fraction of longer reorganizations, as shown in Table 9. All results we present are an average overat least 20 differently seeded workloads. Each workload has 250 operations per client, whereas the first 10warm-up transactions for each client have not been included into statistics.

We conducted the tests in the S-NF, NS-F, and S-F models. For the NS-F and S-F models, failures were

12

randomly generated using the exponential distribution as described in Section 5.1. We used MTTF=1/λvalue of 90 seconds in most of our experiments, which led to 5% of failed operations over all operationtypes. Percent numbers differed for operations of different types because of the variation in Tr. For example,there were 3.3% of failed transactions for the 3 second long Update operation. In order to test the effect offailure rates, we also ran a set of experiments with MTTF value of 180 seconds, which led to 2.5% of failedtransactions for all operation types and 1.65% of failed transactions for Update. Recovery time was alsoexponentially distributed with the average of 5 seconds.

Our testbed provides an option either to drop failed transactions or retry them until successful. Ourexperiments confirm that this choice does not have any impact on the performance of SP leases, as suggestedin Section 5.1.

We also present details pertaining to request rate and concurrency because they (along with recoverytime and lock scheduler details) influence contention in LS leases. All workloads were replayed by 4 clientsrunning in parallel. Similarly to failures, request arrivals were modelled by a Poisson process. We usedone Poisson process for all operations; the type of the next request was independently distributed accordingto the percentages in Table 9. We employed the following values for the average request rate: 1/5, 1/20,and 1/40 operations per second. These rates kept the server busy 92, 23, and 11.5 percent of the time,respectively.

8 Experimental results

This section presents the results of our experiments. Unless specifically indicated otherwise, the data are forfixed-duration leases, that is Tl is fixed and it does not vary, e.g., for different operation types. Figure 10explores the effect of our prediction technique.

All results are shown in the form of dependency on Tl. We use a logarithmic scale for the Tl axis. Since forSP leases, we have not found any interesting variation between results for different operation types, Figures 6to 12 present data only for Update, even though the workload was mixed as described in Section 7. In thesegraphs, the scale for Tl is based on Tr rather than absolute numbers because the shape of dependenciesfollows Tr/Tl ratio. The absolute Tr value for Update was 3 seconds on average as indicated in Table 8.

Tr/3 Tr/2 Tr 2Tr0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Tl

Leas

e In

effic

ienc

y

NS−FS−FS−NF

Figure 6: LI for different models

13

Figure 6 shows lease inefficiency (LI) for the S-NF, NS-F, and S-F models. As expected for the moderatefailure rates we used, lease inefficiency due to false sharing is significantly higher than lease inefficiency dueto failures. The curves for S-NF and S-F are becoming meaningfully different only for values of Tl exceedingTr. The values for these models reach as high as 0.5 when Tl approaches Tr. LI values for NS-F are muchlower and the shape of the LI curve for NS-F will be better visible on Figure 8(a). The curves for S-NF andS-F follow the pattern that is characteristic for false-sharing: for i ∈ N, LI is close to 0 when Tl = Tr/i.As Tl increases, LI rises and then sharply drops at Tr/(i − 1). This cycle-based pattern continues until Tl

reaches Tr, after which LI rises (first rapidly and then slowly) and asymptotically reaches 1.

Tr/3 TrTr/2 2Tr 3Tr0

0.2

0.4

0.6

0.8

Tl

Leas

e In

effic

ienc

y

Tr/3 Tr/2 Tr 2Tr 3Tr

2000

4000

6000

8000

10000

Tr

Tl

Leas

e ow

ners

hip

(ms)

LI LO WLO

Figure 7: Tlo, Twlo, and LI for S-NF

Figure 7 shows lease ownership Tlo, wasted lease ownership Twlo, and LI for the S-NF model. Once again,all the curves follow a characteristic cyclic pattern. The Tlo and Twlo curves are Tr apart as expected. Notethe peculiar fact that Twlo and LI do not reach 0 at the minimums as the theoretical analysis predict themto do. This happens because the experimental dependency reflects the non-deterministic overhead of requestprocessing, which is ignored in the analytical model. This overhead slightly smoothens the drop but theresulting values are still close to 0.

Figures 8(a) and 8(b) contrast theoretical and experimental data for LI, Tlo, and Twlo in the NS-F model.The curves are not identical but they are very similar, which confirms our analysis. In particular, thesmall magnitude of the difference between them indicates that the impact of request processing overhead isgenerally insignificant. Figure 8(a) additionally offers a close-up view of the LI curve in Figure 6 and showsthat the absolute values lie in the range between 0.5% and 2% for the typical Tl values.

Similarly, Figures 9(a) and 9(b) present theoretical and experimental data for LI, Tlo, and Twlo data inthe S-F model. Since the effect of false sharing dominates that of failures, the curves are very similar tothose of Figure 7. The difference between the theoretical and experimental dependencies is minor and almostindistinguishable at the presented scale.

In Figure 10, we examine the tradeoff between LI and the number of request messages (both acquire andrenew) that the lessee needs to send. The values are for the S-F model. The optimal balance is reached inTl = Tr where LI is very close to 0 and only one acquire message has to be sent. Our prediction techniqueindeed achieves this balance as indicated by the data prediction outcome (a single point) in the figure.

Note that the results for Tl slightly exceeding Tr are almost as good as those for Tl = Tr while the outcomefor Tl slightly smaller than Tr is much worse. This observation suggests that when accurate prediction isimpossible, it is better to use a slightly bigger Tl value. This is especially important because of secondarynon-deterministic effects, such as request processing overhead, that may slightly skew the distributions.

14

Tr/3 Tr/2 TrTr/4Tr/12 Tr/6Tr/80

0.005

0.01

0.015

0.02

Tl

Leas

e In

effic

ienc

y

Measured LITheoretical LI

(a) Theoretical and experimental LI

Tr/3 Tr/2 TrTr/6 Tr/4Tr/8Tr/12 2Tr0

500

1000

1500

2000

2500

3000

3500

Tl

Leas

e ow

ners

hip

(ms)

Measured LOTheoretical LOMeasured WLOTheoretical WLO

(b) Theoretical and experimental Tlo and Twlo

Figure 8: Theoretical and experimental lease performance for NS-F

Tr/3 Tr/2 Tr 2Tr 3Tr0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Tl

Leas

e In

effic

ienc

y

Measured LITheoretical LI

(a) Theoretical and experimental LI

Tr/3 Tr/2 Tr 2Tr 3Tr0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

Tl

Leas

e ow

ners

hip

(ms)

Measured LOTheoretical LOMeasured WLOTheoretical WLO

(b) Theoretical and experimental Tlo and Twlo

Figure 9: Theoretical and experimental lease performance for S-F

15

Tr/3 Tr/2 Tr 2Tr 3Tr0

1

2

3

4

Tl

Mes

sage

s

Tr/3 Tr/2 Tr 2Tr 3Tr0

0.2

0.4

0.6

0.8

1

Tl

Leas

e In

effic

ienc

y

Used messages LI

Predictor point

Figure 10: LI and the number of messages for fixed and predicted duration

Tr/3 Tr/2 Tr 2Tr0

0.01

0.02

0.024

Tl

Leas

e In

effic

ienc

y

1.65% failures3.3% failures

(a) In the NS-F model

Tr/3 Tr/2 Tr 2Tr0

0.1

0.2

0.3

0.4

0.5

Tl

Leas

e In

effic

ienc

y

1.65% failures3.3% failuresno failures

(b) In the S-F model

Figure 11: LI for different failures rates

16

Observe that a predictor that always selects Tl between Tr and 1.1 ∗Tr would still lead to very good results,which illustrates the potential of prediction for practical systems.

Additionally note that LI in Tl = Tr/2 is smaller than in Tl = Tr; the difference may become meaningfulfor high failure rates. If the need to send one extra renew message is not an issue, it may be desirable forthe predictor to target Tl = Tr/2 instead of Tl = Tr in such settings.

Figure 11(a) shows LI for different failure rates in the NS-F model. We can see that the shape of thecurves is similar but the absolute values substantially differ. This indicates, in particular, that failuresmay significantly contribute to LI for higher failure rates, that are typical for some mobile and peer-to-peerenvironments.

Similarly, Figure 11(b) shows LI for different failure rates in the S-F model. In this model, however, thesignificance of failure rates is much less pronounced because the effect of false sharing dominates that offailures.

Tr/3 Tr/2 Tr 2Tr0

100%

200%

300%

400%

500%

600%

50%

Tl

σ(LI

)/LI

Figure 12: Standard deviation of LI in S-F

In Figure 12, we examine the standard deviation of LI in the S-F model. Presented standard deviationvalues are scaled with respect to the corresponding LI values. It turns out that for values of Tl close to Tr/i,i ∈ N, the standard deviation takes a sharp rise followed by a slightly less sharp drop. This is due to thecyclic LI pattern that is characteristic for false-sharing. An LI value for Tl = Tr/i can be greater than an LIvalue for Tl slightly exceeding Tr/i by a factor of 50 in our experiments.

This is where secondary non-deterministic effects such as load on the machine play an important role.While Tl values slightly exceeding Tr/i are optimal for LI, they may lead to a very high LI variance. Ifstability of LI and execution times is important (which is the case, e.g., in real-time applications), then Tl

values taken from the middle range of [Tr/i, Tr/(i + 1)] may provide a better balance between low LI andlow LI variance.

Figure 13 presents a number of characteristics for LS leases in the S-NF model: Twait/(Twait + Tulo)ratio for request rates of 0.2 and 0.025 ops per second, the percent of operations that experience blocking(Twait > 0) for the same request rates, and LI. As we observed in Section 5.1, LI still remains a function of Tl

and Tr for LS leases and it does not depend on contention and the request rate. Both Twait and the percentof blocked operations represent the contention and correspond to typical metrics in concurrency performancemodeling for databases [1,3]. We opted to present the Twait/(Twait +Tulo) ratio as a metric more meaningfulin our context than the absolute value of Twait.

17

1s 2s 5s 10s 20s 40s1/4s0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Tl (sec)

Twait

/(Twait

+Tulo

), rate 0.2

Twait

/(Twait

+Tulo

), rate 0.025

blocking %, rate 0.2blocking %, rate 0.025Lease Inefficiency

Figure 13: Results for LS leases in S-NF

Unlike the other graphs, this figure shows aggregate data values for all operation types. In particular, theshape of the aggregate LI curve is different compared to the LI curve for Update in other presented graphs.

We can see that while being affected by Tl, the percent of blocked operations is not strongly correlatedwith either Tl or LI. The dependency is quite complex: while increased Tl and longer lease ownership maylead to higher contention, they also cause shorter lease requests for Update and Read operations to becomelonger. Since there is a limited number of concurrent clients in the system and each client invokes workloadoperations sequentially, a single long Reorg operation would block a smaller number of concurrent Updateand Read operations.

Note that in this case, Twait would still increase even though the number of blocked operation woulddecrease. Indeed, we can see that unlike the percent of blocked operations, the Twait/(Twait + Tulo) ratioexhibits a strong correlation with Tl and LI.

9 Conclusions and future work

We have presented a performance-oriented model for evaluating efficiency of lease-based schemes and atechnique for predicting the optimal lease duration. Future work may include modeling lease-ownershipcycle as a stochastic process, which may potentially lead to an analytical model for contention in LS leases.

References[1] R. Agrawal, M. J. Carey, and M. Livny. Concurrency control performance modeling: alternatives and implications. ACM

Trans. Database Syst., 12(4):609–654, 1987.

[2] D. Bacon and P. Sweeney. Fast static analysis of C++ virtual function calls. In OOPSLA Object-Oriented ProgrammingSystems, Languages, and Applications, San Jose, California, Oct 1996. ACM.

[3] P. A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Database Systems. AddisonWesley, Reading, MA, 1987.

[4] J. Bogda and U. Holzle. Removing unnecessary synchronization in Java. In OOPSLA, pages 35–465, Nov 1999.

[5] P. Cao and C. Liu. Maintaining strong cache consistency in the world-wide web. In ICDCS, May 1997.

[6] M. J. Carey, D. J. DeWitt, and J. F. Naughton. The OO7 benchmark. SIGMOD Record (ACM Special Interest Group onManagement of Data), 22(2):12–21, 1993.

18

[7] R. G. G. Cattell and J. Skeen. Object operations benchmark. TODS, 17(1):1–31, 1992.

[8] V. Duvvuri, P. Shenoy, and R. Tewari. Adaptive leases: A strong consistency mechanism for the world wide web. IEEETransactions on Knowledge and Data Engineering, 15(5):1266–1276, 2003.

[9] C. Gray and D. Cheriton. Leases: an efficient fault-tolerant mechanism for distributed file cache consistency. In symposiumon Operating systems principles, pages 202–210, 1989.

[10] M. Hind. Pointer analysis: Haven’t we solved this problem yet? In 2001 ACM SIGPLAN-SIGSOFT Workshop onProgram Analysis for Software Tools and Engineering (PASTE’01), Snowbird, Utah, Jun 2001. ACM.

[11] A. D. Joseph, J. A. Tauber, and M. F. Kaashoek. Mobile computing with the Rover toolkit. IEEE Transactions onComputers: Special issue on Mobile Computing, Mar 1997.

[12] J. J. Kistler and M. Satyanarayanan. Disconnected operation in the Coda file system. In symposium on Operating systemsprinciples, pages 213–225. ACM, Oct 1991.

[13] K. Kvilekval and A. Singh. Spree: Object prefetching for mobile computers. In International Conference on DistributedObjects and Applications, pages 282–289, 2004.

[14] Ozone Group. Ozone OODB. Technical report, www.ozone-db.org, 2001.

[15] K. Petersen, M. J. Spreitzer, D. B. Terry, M. M. Theimer, and A. J. Demers. Flexible update propagation for weaklyconsistent replication. In 16th ACM Symposium on Operating Systems Principles, pages 288–301, Oct 1997.

[16] E. Ruf. Effective synchronization removal for Java. In SIGPLAN Conference on Programming Language Design andImplementation (PLDI2000), Jun 2000.

[17] Sun Microsystems, JINI. http://jini.org.

[18] K. Trivedi. Probability and Statistics with Reliability, Queuing, and Computer Science Applications. John Wiley andSons, 2001.

[19] R. Vitenberg, K. Kvilekval, and A. K. Singh. Increasing concurrency in databases using program analysis. In EuropeanConference on Object-Oriented Programming (ECOOP), Oslo, Norway, Jun 2004. Springer Verlag.

[20] J. Yin, L. Alvisi, M. Dahlin, and C. Lin. Volume leases for consistency in large-scale systems. IEEE Trans. on Knowl.and Data Eng., 11(4):563–576, 1999.

19

A Appendix: derivation of the analytical formulae

Consider the lease ownership time Tlo. It will always be Tr in an NS-NF system (independently of Tl). Inan S-NF system, the lease ownership time will always be dTr/TleTl independently of tR.

In an S-F system, Tlo ∈ [Tl, Tm]. In an NS-F system, Tlo ∈ [min(Tl, Tr), Tm]. The average lease ownershiptime for an NS-F system can be expressed as follows (see Table 4):

TloNS-F

= γ + Tre−λTr (4)

Proof.

TloNS-F

=∫ ∞

0

Tlo(x)pdf(x)dx =∫ Tr

0

d x

TleTlλe−λxdx +

∫ ∞

Tr

Trλe−λxdx (5)

Let us develop both subexpressions.∫ ∞

Tr

Trλe−λxdx = −Tr

∫ ∞

Tr

e−λxd(−λx) = −Tr

∫ −∞

−λTr

eydy = Tr(e−λTr − limy→−∞

ey) = Tre−λTr (6)

∫ Tr

0

d x

TleTlλe−λxdx = Tl((

bTrTlc∑

a=1

−a

∫ aTl

(a−1)Tl

e−λxd(−λx))− dTr

Tle∫ Tr

bTrTlcTl

e−λxd(−λx)) = (7)

= Tl((

bTrTlc∑

a=1

−a

∫ −λaTl

−λ(a−1)Tl

eydy)−dTr

Tle∫ −λTr

−λbTrTlcTl

eydy) = Tl((

bTrTlc∑

a=1

−a(e−λaTl−e−λ(a−1)Tl))−dTr

Tle(e−λTr−e

−λbTrTlcTl))

Let us develop both subexpressions of Equation 7.

bTrTlc∑

a=1

−a(e−λaTl − e−λ(a−1)Tl) =

bTrTlc∑

a=1

e−λ(a−1)Tl − bTr

Tlce−λbTr

TlcTl (8)

bTrTlc∑

a=1

e−λ(a−1)Tl =

bTrTlc−1∑

a=0

1(e−λTl)a =1− e

−λTlbTrTlc

1− e−λTl(9)

dTr

Tle(e−λTr − e

−λbTrTlcTl)) = (bTr

Tlc+ 1)(e−λTr − e

−λbTrTlcTl)) (10)

Equation 10 holds because dTr

Tle 6= bTr

Tlc+ 1 only if Tr is a multiple of Tl. In this case, the second part of the

expression is equal to 0.If we merge Equation 9 into Equation 8, then Equations 8 and 10 into Equation 7, we obtain that

∫ Tr

0

d x

TleTlλe−λxdx = Tl(

1− e−λTlbTr

Tlc

1− e−λTl− bTr

Tlce−λbTr

TlcTl − dTr

Tle(e−λTr − e

−λbTrTlcTl)) = (11)

= Tl(1− e

−λTlbTrTlc

1− e−λTl+ e

−λbTrTlcTl − (bTr

Tlc+ 1)e−λTr ) = γ

Finally we merge Equations 6 and 11 into Equation 5 and obtain Equation 4, which concludes the proof.

The average lease ownership time for an S-F system (see Table 5) is derived in a similar way:

TloS-F

=∫ ∞

0

Tlo(x)pdf(x)dx =∫ Tr

0

d x

TleTlpdf(x)dx +

∫ ∞

Tr

Tm pdf(x)dx = γ + Tme−λTr

.

20

Twlo is always 0 in an NS-NF system so that there is no penalty for using long leases. In an S-NF system,Twlo = Tm − Tr, while in an S-F system, Twlo ∈ [max(0, Tl − Tr), Tl]. In an NS-F system, Twlo ∈ [0, Tl]. Theaverage Twlo in an NS-F system can be expressed as follows (see Table 5):

TwloNS-F

= γ − γ′ (12)

Proof.

TwloNS-F

=∫ Tr

0

(d x

TleTl − x)pdf(x)dx =

∫ Tr

0

d x

TleTlpdf(x)dx−

∫ Tr

0

x pdf(x)dx

We have already developed the first subexpression in Equation 11. To conclude the proof, we apply thestandard integral formula ∫

xeaxdx =eax

a2(ax− 1)

and derive that ∫ Tr

0

xpdf(x)dx =∫ Tr

0

xλe−λxdx =1λ

(e−λTr (−λTr − 1) + 1) = γ′

The average Twlo for an S-F system (see Equation 1) is derived in a similar way:

TwloS-F

=∫ Tr

0

(d x

TleTl − x) pdf(x)dx +

∫ ∞

Tr

(Tm − Tr) pdf(x)dx = γ − γ′ + (Tm − Tr)e−λTr .

Finally, consider lease inefficiency LI = Twlo/Tlo. It is always 0 in an NS-NF system and 1 − Tr/Tm inan S-NF system. The average LI in an NS-F system can be expressed as follows (see Equation 2):

LINS-F

=

= e−λTlbTr

Tlc − e−λTr +

1 + eλTl(λTl − 1)λTl

bTrTlc∑

a=1

e−λaTl

a−

− 1dTr

TleλTl

(e−λTr (−λTr − 1)− e−λbTr

TlcTl(−λbTr

TlcTl − 1)).

Proof.

∫ ∞

0

Twlo(x)/Tlo(x) pdf(x)dx =∫ Tr

0

(d xTleTl − x)

d xTleTl

pdf(x)dx =∫ Tr

0

pdf(x)dx− 1/Tl

∫ Tr

0

x

d xTlepdf(x)dx (13)

Let us develop both subexpressions of Equation 13.

∫ Tr

0

pdf(x)dx = −∫ Tr

0

e−λxd(−λx) = −(e−λTr − 1) (14)

∫ Tr

0

x

d xTlepdf(x)dx =

bTrTlc∑

a=1

1a

∫ aTl

(a−1)Tl

xpdf(x)dx +∫ Tr

bTrTlcTl

x

dTr

Tlepdf(x)dx (15)

Let us develop both subexpressions of Equation 15.

∫ Tr

bTrTlcTl

x

dTr

Tlepdf(x)dx =

1dTr

Tleλ (e−λTr (−λTr − 1)− e

−λbTrTlcTl(−λbTr

TlcTl − 1)) (16)

21

bTrTlc∑

a=1

1a

∫ aTl

(a−1)Tl

xpdf(x)dx =1λ

bTrTlc∑

a=1

1a(e−λaTl(−λaTl − 1)− e−λ(a−1)Tl(−λ(a− 1)Tl − 1)) = (17)

=1λ

bTrTlc∑

a=1

e−λaTl

a(−λaTl − 1− eλTl(−λaTl + λTl − 1)) =

=1λ

(λTl(eλTl − 1)

bTrTlc∑

a=1

e−λaTl − (1 + eλTl(λTl − 1))

bTrTlc∑

a=1

e−λaTl

a) =

= Tl(1− e−λTlbTr

Tlc)− 1 + eλTl(λTl − 1)

λ

bTrTlc∑

a=1

e−λaTl

a

We obtain Equation 2 by merging Equations 17 and 16 into Equation 15, subsequently merging the latterand Equation 14 into Equation 13, and performing simplifications.

Average LI for an S-F system is greater than the average LI for an NS-F system by∫ ∞

Tr

Tm − Tr

Tmpdf(x)dx =

Tm − Tr

Tme−λTr .

This results in the following formula (see Equation 3):

LIS-F

= LINS-F

+Tm − Tr

Tme−λTr .

There is an additional important characteristic, namely, the number of messages sent in a lease-basedsystem: a lessee always sends a single acquire request. It sends one release request in NS-F and NS-NFsystems and no release requests in S-F and S-NF systems. The number of renew requests will always bedTlo/Tle − 1 in any system. Obviously, from the standpoint of renew requests, the optimal Tl is equal toor greater than Tr. The total number of request messages (one acquire and all renew requests) can beexpressed as follows: dTr/Tle both for NS-NF and S-NF systems. For NS-F and S-F systems, it is

∫ ∞

0

dTlo(x)Tl

epdf(x)dx =∫ Tr

0

d x

Tleλe−λxdx +

∫ ∞

Tr

dTr

Tleλe−λxdx =

γ

Tl+ dTr

Tlee−λTr .

22