Methods and apparatus for managing deactivation and shutdown of a server

Claim 2

A computer implemented method for managing clients of a server that is arranged to provide services to a plurality of clients, the server being responsive to service requests from various clients and deactivation requests, the method including the computer controlled steps of: (a) in response to each service request, determining only once for a particular service request whether the server is in a locked state, wherein when the server is in the locked state the server will reject and not handle the service request and thus the server will never perform a requested service corresponding to the particular service request if the particular service request was received while the server is in the locked state, but, when the server is in an unlocked state, the server will accept and subsequently handle the service request, and incrementing a transaction counter by a predetermined value when it is determined that the server is in the unlocked state, the transaction counter being indicative of the number of service requests actively utilizing the server; (b) performing the requested service when it is determined in step (a) that the server is in the unlocked state; (c) decrementing the transaction counter by the predetermined value after each requested service having a corresponding service request that was accepted has been completed; (d) in response to a deactivation request, setting the server to the locked state and checking the transaction counter to determine whether there are any active service requests prior to deactivating the server; and (e) when it is determined that there is at least one active service request, waiting to deactivate the server until it is determined based on the transaction counter that all of the active service requests have been completed, wherein the server is deactivated only after it is determined that all of the active service requests have been completed, whereby when the server is to be deactivated, new service requests are refused since the server is in the locked state and existing service requests are completed prior to deactivation.

Claim 3

A computer implemented method as recited in claim 1 wherein the server is a server computer process.

Claim 4

A computer implemented method as recited in claim 1 wherein the server is a server object.

Claim 5

A computer implemented method as recited in claim 1 wherein the server is a computer service including a plurality of objects.

Claim 6

A computer implemented method as recited in claim 1 wherein in response to each service request, the server invokes a check in operation which accomplishes the locked state determining and the transaction counter incrementing steps.

Claim 7

A computer implemented method as recited in claim 5 wherein the state of the server is indicated by a lock flag.

Claim 8

A computer implemented method as recited in claim 6 wherein the check in operation further comprises a computer controlled step of returning said state of said lock flag to said server.

Claim 9

A computer implemented method as recited in claim 6 wherein said check in operation further comprises the computer controlled steps of: prior to both the locked state determining and the transaction counter incrementing steps, locking a mutex associated with said lock flag and said transaction counter such that said lock flag and said transaction counter are protected from all other computer threads of execution; and subsequent to both the locked state determining and the transaction counter incrementing steps, unlocking said mutex.

Claim 10

A computer implemented method as recited in claim 1 wherein at the completion of each requested service, the server invokes a check out operation which accomplishes the transaction counter decrementing step.

Claim 11

A computer implemented method as recited in claim 9 wherein the check out operation further comprises the steps of: prior to said transaction counter decrementing step, locking a mutex associated with said transaction counter such that said transaction counter is protected from all other computer threads of execution; subsequent to said transaction counter decrementing step, determining if said transaction counter indicates that there are active service requests; broadcasting on a condition variable associated with said mutex when it is determined that there are no active service requests; and subsequent to said transaction counter decrementing step, unlocking said mutex.

Claim 12

A computer implemented method as recited in claim 1 wherein in response to a deactivation request, the server invokes a lock up operation which accomplishes the setting the server to the locked state step.

Claim 13

A computer implemented method as recited in claim 11 wherein the state of the server is indicated by a lock flag.

Claim 14

A computer implemented method as recited in claim 12 wherein the lock up operation accomplishes the setting the server to the locked state step by setting the lock flag.

Claim 15

A computer implemented method as recited in claim 13 wherein the lock up operation further comprises the computer controlled steps of: prior to said setting the server to the locked state step, locking a mutex associated with said lock flag such that said lock flag is protected from all other computer threads of execution; and subsequent to said setting the server to the locked state step, unlocking said mutex.

Claim 16

A computer implemented method as recited in claim 1 wherein in response to a deactivation request, the server invokes a flush operation which performs the checking the transaction counter step.

Claim 17

A computer implemented method as recited in claim 15 wherein when it is determined that there is at least one active service request the flush operation further comprises the computer controlled steps of: blocking a thread of execution associated with said flush operation on a condition variable associated with said transaction counter; and in response to a broadcast on said condition variable, unblocking said flush operation thread of execution.

Claim 18

A computer implemented method as recited in claim 15 wherein when it is determined that there are no active server requests, the flush operation further comprises a computer controlled step of notifying the server that the flush operation is complete.

Claim 19

A computer implemented method as recited in claim 15 wherein when it is determined that there are no active server requests, the flush operation further comprises a computer controlled step of deleting the server.

Claim 20

A computer implemented method as recited in claim 15 wherein the flush operation further comprises the computer controlled steps of: prior to said checking the transaction counter step, locking a mutex associated with said transaction counter such that said transaction counter is protected from all other computer threads of execution; and subsequent to said checking the transaction counter step, unlocking said mutex.

Claim 21

A computer implemented method as recited in claim 1 further including a step of setting the server to the unlocked state in response to an activation request.

Claim 22

A computer implemented method as recited in claim 20 wherein said server invokes a reopen operation which accomplishes the setting the server to the unlocked state step.

Claim 23

A computer implemented method as recited in claim 21 wherein the state of the server is indicated by a lock flag.

Claim 24

A computer implemented method as recited in claim 22 wherein the reopen operation comprises the computer controlled step of setting the lock flag to indicate that the state of the server is unlocked.

Claim 25

A computer implemented method as recited in claim 23 wherein the reopen operation further comprises the computer controlled steps of: prior to said step of setting the lock flag, locking a mutex associated with said lock flag such that said lock flag is protected from all other computer threads of execution; and subsequent to said step of setting the lock flag, unlocking said mutex.

Claim 26

A computer implemented method for managing clients of a server that is arranged to provide services to a plurality of clients, the server being responsive to service requests from various clients and deactivation requests, the method including the computer controlled steps of: in response to each service request, invoking a check in operation, the check in operation including the computer controlled steps of determining only once for a particular service request whether the server is in a locked state, wherein when the server is in the locked state the server will reject and not handle the service request and thus the server will never perform a requested service corresponding to the particular service request if the particular service request was received while the server is in the locked state, but, when the server is in an unlocked state the server will accept and subsequently handle the service request, and incrementing a transaction counter by a predetermined value when it is determined that the server is in the unlocked state, the transaction counter being indicative of the number of service requests actively utilizing the server; performing the requested service when it is determined that the server is in the unlocked state; in response to a service request being completed, invoking a check out operation that decrements the transaction counter by the predetermined value; in response to a deactivation request, invoking a lock up operation that sets the server to the locked state, wherein in the locked state the server completes all active service requests but rejects new service requests; in response to a deactivation request, performing any necessary deactivation functions and then invoking a flush operation that checks the transaction counter to determine whether there are any active service requests prior to deactivating the server; and when it is determined that there is at least one active service request, waiting to deactivate the server until after it is determined based on the transaction counter that all of the active services have been completed, whereby when the server is to be deactivated, new service requests are refused and existing service request are completed prior to deactivation.

Claim 27

A computer implemented method for managing clients of a server that is arranged to provide services to a plurality of clients, the server being responsive to service requests from various clients and deactivation requests, the method including the computer controlled steps of: in response to each service request, invoking a check in operation, the check in operation including the computer controlled steps of determining only once for a particular service request whether the server is in a locked state, wherein when the server is in the locked state the server will reject and not handle the service request and thus the server will never perform a requested service corresponding to the particular service request if the particular service request was received while the server is in the locked state, but, when the server is in an unlocked state the server will accept and subsequently handle the service request, and incrementing a transaction counter by a predetermined value when it is determined that the server is in the unlocked state, the transaction counter being indicative of the number of service requests actively utilizing the server; performing the requested service when it is determined that the server is in the unlocked state; in response to a service request being completed, invoking a check out operation that decrements the transaction counter by the predetermined value; in response to a deactivation request, invoking a lock up operation that sets the server to the locked state, wherein in the locked state the server completes all active service requests but rejects new service requests; in response to a deactivation request, performing any necessary deactivation functions and then invoking a flush operation that checks the transaction counter to determine whether there are any active service requests prior to deactivating the server; and when it is determined that there is at least one active service request, waiting to deactivate the server until after it is determined based on the transaction counter that all of the active services have been completed, whereby when the server is to be deactivated, new service requests are refused and existing service request are completed prior to deactivation.

Claim 28

A computer implemented method as recited in claim 25 wherein the server is selected from the group consisting of a server process, a server object and a computer service comprising a plurality of objects.

Claim 29

A computer implemented method as recited in claim 25 wherein the state of the server is indicated by a lock flag.

Claim 30

A computer implemented method as recited in claim 27 wherein the check in operation further comprises the computer controlled step of returning said state of said lock flag to said server.

Claim 31

A computer implemented method as recited in claim 28 wherein the lock up operation accomplishes the setting the server to the locked state step by setting the lock flag.

Claim 32

An usher device for use on a computer system, said usher device being arranged to manage a plurality of clients of a computer server and assist in an orderly shutdown of said computer server, said usher device comprising: a transaction counter indicative of the number of client service requests actively utilizing said computer server, a client service request that is actively utilizing said computer server being a client service request that has been accepted by the usher but has not yet been completed by the computer server; a check in device operable to increment said transaction counter by a predetermined value; a check out device operable to decrement said transaction counter by said predetermined value; a lock up device operable to lock up said computer server such that when said computer server is locked up it does not accept new client service requests but continues performing any active service requests, whereby said computer server will never perform new client service requests received while the computer server is locked up; and a flush device operable to shut down said usher device when said computer server is locked up and after waiting until said transaction counter indicates that there are no active service requests, wherein the flush device is operable to deactivate the server when it is determined based on the transaction counter that there are not active service requests.

Claim 33

An usher device for use on a computer system, said usher device being arranged to manage a plurality of clients of a computer server and assist in an orderly shutdown of said computer server, said usher device comprising: a transaction counter indicative of the number of client service requests actively utilizing said computer server, a client service request that is actively utilizing said computer server being a client service request that has been accepted by the usher but has not yet been completed by the computer server; a check in device operable to increment said transaction counter by a predetermined value; a check out device operable to decrement said transaction counter by said predetermined value; a lock up device operable to lock up said computer server such that when said computer server is locked up it does not accept new client service requests but continues performing any active service requests, whereby said computer server will never perform new client service requests received while the computer server is locked up; and a flush device operable to shut down said usher device when said computer server is locked up and after waiting until said transaction counter indicates that there are no active service requests, wherein the flush device is operable to deactivate the server when it is determined based on the transaction counter that there are not active service requests.

Claim 34

An usher device as recited in claim 30 wherein said flush device is further operable to broadcast to said computer server when it has completed its functions.

Claim 35

An usher device as recited in claim 30 further comprising a reopen device operable to unlock said computer server such that said computer server can perform services for said plurality of clients.

Claim 36

An usher device as recited in claim 30 wherein said computer server is a computer process.

Claim 37

An usher device as recited in claim 30 wherein said computer server is an object.

Claim 38

An usher device as recited in claim 30 wherein said computer server is a computer service comprising a plurality of objects arranged to work together to provide services to said plurality of clients.

Claim 39

An usher device as recited in claim 30 wherein said usher device is resident within said computer server.

Claim 40

An usher device as recited in claim 30 wherein said usher device is resident external to said computer server.

Claim 41

An usher device as recited in claim 30 wherein said lock up device includes a lock up flag indicating the state of the computer server.

Claim 42

An usher device as recited in claim 38 wherein said lock up device is arranged to set said lock up flag to indicate that the state of the computer server is locked.

Claim 43

An usher device as recited in claim 38 further including a mutex associated with said transaction counter and said lock flag.

Claim 44

An usher device as recited in claim 40 wherein said check in device is further operable to: lock said mutex such that said transaction counter and said lock flag are protected from all other threads of execution; determine the state of said lock flag and, when the state of said lock flag indicates that said computer server is unlocked, increment said transaction counter by said predetermined value; and unlock said mutex.

Claim 45

An usher device as recited in claim 30 further comprising a mutex associated with said transaction counter.

Claim 46

An usher device as recited in claim 42 wherein said check out device is further operable to: lock said mutex such that said transaction counter is protected from all other threads of execution; and unlock said mutex.

Claim 47

An usher device as recited in claim 40 wherein said lock up device is further operable to: lock said mutex such that said lock flag is protected from all other threads of execution; and unlock said mutex.

Claim 48

An usher device as recited in claim 44 further including a condition variable associated with said transaction counter.

Claim 49

An usher device as recited in claim 45 wherein when said transaction counter indicates that there is at least one active service request, said flush device responds by blocking a thread of execution associated with said flush device on said condition variable.

Claim 50

An usher device as recited in claim 46 wherein when said transaction counter transitions from indicating that there is one active service request to indicating that there are no active service requests, said check out device responds by broadcasting a thread wakeup call on said condition variable.

Claim 51

An usher device as recited in claim 47 wherein said flush device responds to said thread wakeup call by unblocking said thread of execution associated with said flush device.

Claim 52

A computer system comprising: a central processing unit; a memory device accessed by said central processing unit; and an usher device as recited in claim 48.

Claim 53

A computer system as recited in claim 49 further including an input/output device coupled to at least one of central processing unit and said memory device.

Claim 54

A distributed object operating environment comprising: a plurality of computers as recited in claim 50; and a computer network interconnecting said plurality of computer systems via the input/output device of each one of said plurality of computer systems.