LEASE AND RENUAL CALL TIME

........................................................................................
In normal .NET environment objects lifetime is managed by garbage collector. But in remoting environment remote clients can access objects which are out of control of garbage collector. Garbage collector boundary is limited to a single PC on which framework is running; any remote client across physical PC is out of control of GC (Garbage Collector).

This constraint of garbage collector leads to a new way of handling lifetime for remoting objects, by using concept called as “LeaseTime”. Every server side object is assigned by default a “LeaseTime” of five minutes. This leasetime is decreased at certain intervals.

Again for every method call a default of two minutes is assigned. When i say method call means every call made from client. This is called as “RenewalOnCallTime”.

Let’s put the whole thing in equation to make the concept more clear.

Total Remoting object life time = LeaseTime + (Number of method calls) X (RenewalTime).

If we take NumberOfMethodCalls as one.

Then default Remote Object Life Time = 5 + (1) X 2 = 10 minutes (Everything is in
minutes)

When total object lifetime is reduced to zero, it queries the sponsor that should the object be destroyed. Sponsor is an object which decides should object Lifetime be renewed. So it queries any registered sponsors with the object, if does not find any then the object is marked for garbage collection. After this garbage collection has whole control on the object lifetime. If we do not foresee how long a object will be needed specify the “SponsorShipTimeOut” value.

SponsorShipTimeOut is time unit a call to a sponsor is timed out.

“LeaseManagerPollTime” defines the time the sponsor has to return a lease time extension.

Marshalling

Marshaling is used when an object is converted so that it can be sent across the network or across application domains. Unmarshaling creates an object from the marshaled data. here are two ways to do marshalling :-

Marshal-by-value (MBV) :- In this the object is serialized into the channel, and a copy of the object is created on the other side of the network. The object to marshal is stored into a stream, and the stream is used to build a copy of the object on the other side with the unmarshalling sequence.

Marshaling-by-reference (MBR):- Here it creates a proxy on the client that is used to communicate with the remote object. The marshaling sequence of a remote object creates an ObjRef instance that itself can be serialized across the network.

Objects that are derived from “MarshalByRefObject” are always marshaled by reference. All our previous samples have classes inherited from “MarshalByRefObject”

To marshal a remote object the static method RemotingServices.Marshal() is sed.RemotingServices.Marshal() has following overloaded versions:-

public static ObjRef Marshal(MarshalByRefObject obj)
public static ObjRef Marshal(MarshalByRefObject obj, string objUri)
public static ObjRef Marshal(MarshalByRefObject obj, string objUri,Type
requestedType)

The first argument obj specifies the object to marshal. The objUri is the path that is stored within the marshaled object reference; it can be used to access the remote object. The requestedType can be used to pass a different type of the object to the object reference.

This is useful if the client using the remote object shouldn't use the object class but an interface that the remote object class implements instead. In this scenario the interface is the requestedType that should be used for marshaling.
102

RELATED POST


ERROR CHECK LIST FOR INSPECTIONS

WALK THROUGHS IN TESTING

TESTING FOR SPECIALIZED ENVIRONMENTS PART ONE

TESTING FOR SPECIALIZED ENVIRONMENTS PART TWO

VALIDATION TESTING

SYSTEM TESTING


DEBUGGING AND TESTING

DEFECT AMPLIFICATION AND REMOVAL

ITERATIVE SPIRAL MODEL

STANDARD WATER MODEL

CONFIGURATION MANAGEMENT


CONTROLLED TESTING ENVIRONMENT

RISK ANALYSIS PART ONE


RISK ANALYSIS PART TWO

BACK GROUND ISSUES

SOFTWARE REVIEWS PART ONE

SOFTWARE REVIEWS PART TWO

SOFTWARE RELIABILITY

SAFETY ASPECTS

MISTAKE PROOFING

SCRIPT ENVIRONMENT

V MODEL IN TESTING

No comments:

Post a Comment