fig1 is a block diagram of a distributed system in one embodiment of the invention . a central services node 100 , provides services to one or more instances , such as java 2 enterprise edition ( j2ee ) instance 104 and other instances 108 . other instances 108 may be additional j2eee instances or may be instances created using a different paradigm . as used herein , each “ instance ” is a unit in the distributed system ( also referred to as a cluster ), which can be started , stopped and monitored separately . an instance typically contains at least one server process e . g ., process server 110 or 112 . more commonly , an instance includes a dispatcher 114 and more than one server process 110 , 112 . it is also contemplated that more than one dispatcher may reside in a single instance . in one embodiment , each instance runs on one physical server , but more than one instance may run on single physical server . in one embodiment , an instance may be identified within the cluster by a system identification number and an instance number . in one embodiment , the central services node is a special example of a j2ee instance . central services node 100 includes lock server 180 and a message server 190 . message server 190 registers all active server and dispatcher processes within the cluster . when the server goes down , e . g ., crashes or otherwise shuts down , message server is aware of the shutdown and notifies the lock server 180 . this notification is independent of other lock requests that may be occurring . also shared between the instances 104 , 108 is database 106 . lock server 180 includes a lightweight protocol layer 182 , which provides an interface for communication with other processes within the cluster . also in lock server 180 is a lock table 184 retained in shared memory . in some embodiments , a lock requested queue 186 might also be provided . lock request queue 186 permits wait on locking to performed by the lock server 180 . if no wait on locking is permitted and a process requests a lock for data for which a lock already exists in the lock table 184 , lock server 180 generates an exception and sends it back to the requesting process . thus , when a request is received through the lightweight protocol layer 182 , the lock server checks lock table 184 and determines whether the requested lock is permitted based on those locks already in existence . if the lock is available , lock server 180 adds an entry to lock table 184 and grants the lock to the requesting process . embodiments in which wait on locking is supported , if the lock is not available , the request is queued in lock requested queue 186 . in one embodiment , lock requested queue may be implemented with a semaphore or a similar synchronization object . additionally , if lock server 180 receives notification from message server 190 that a process has become inactive , lock server 180 checks the lock table 184 for entries owned by that process , clears the entries and releases all corresponding locks . this prevents deadlock conditions where a server process crashes or shuts down with active locks and makes that ( previously locked ) data available to other processors in the system . j2ee server process 110 hosts a java virtual machine ( jvm ) 120 , which may have threads 121 and 122 executing therein . threads 121 and 122 may correspond to client activity , which may be directed over a distributed network ( not shown ) such as the internet . commonly , the client directing a threads activity may be web browser . clients can communicate with the server process using a hypertext transfer protocol ( http ). when one of the threads executing in jvm 120 wishes to obtain read or write access to data within database 106 , the thread requests the lock manager 128 within jvm 120 obtain a read or write lock as the case may be for that data . notably , within a cluster , a read lock can be shared while a write lock should be exclusive . a thread may then register with listener agent 130 . in one embodiment , listener agent 130 may be a dedicated thread that watches the bound queue 126 for responses to the lock requests sent by the lock manager 128 . lock manager 128 sends requests using the java native interface ( jni ) layer 125 through c library 124 to the lock server 180 on the central services node 100 . in one embodiment , the lock manager 128 provides a basic application programming interface ( api ) including the following calls : lock ( owner , argument , modus ); unlock ( owner , argument , modus ) and unlockall ( owner ). in this api , owner is the transaction to which the lock applies . the transaction may be a business transaction or a technical transaction . the argument identifies what data is to be locked and modus indicates whether the lock is to be a read lock or a write lock . as noted above , read locks may be shared , while write locks must be exclusive . in some embodiments , the lock manager 128 may supply additional api for application locking and table locking . with the basic api above as a wrapper around the more restrictive locking types . in this context , additional parameter ( lifetime ) is required in the lock call . lifetime is typically a user session or transaction . in the context of table locking , the argument becomes an identification of the table and the columns to be locked . in some embodiments wait on locking may be supported . in such embodiment , the lock call may specify an additional “ time out ” parameter . the time out parameter specifies a minimum amount of time the owner will wait to receive the lock . if the lock does not become available before the time out parameter is exhausted , the owner will not obtain the lock . j2ee server process 112 hosts jvm 150 . shown as having a plurality of threads 151 - 153 executing therein . locking manager 158 and jvm 150 includes a java library 154 , which permits direct communication with locking server 180 without going through a jni layer or making jni calls . additionally , because the java library 154 is platform independent , it is not necessary to list it on every possible deployment platform . in one embodiment , java library 154 is thread safe and may provide multiple remote connections to the lock server , which can be used in parallel by a plurality of threads 151 - 153 . however , to conserve resources , in one embodiment , the number of connections is limited to , for example , a single connection . in one embodiment , the lock server 180 permits assynchronous communication over a single connection . this permits multiple threads , e . g . threads 151 - 153 to pass requests over a single connection without waiting for the response . moreover , the response may arrive in a different order than the requests were sent . to match requests and responses to the java library 154 , provide a requesting thread , e . g . thread 151 with an identification tag to tag its requests . the thread 151 may then be given exclusive access to the send interface . the thread 151 sends its request and registers with an existing agent to notify the thread 151 if a response with the same identification tag is returned . after registration , the thread releases the send interface so it will be free for use by any other thread , e . g . threads 152 , 153 . any number of other threads may send requests similarly . once a response ( with the identification tag corresponding to thread 151 ) is received , the listing agent notifies the thread 151 and passes the response to thread 151 . listener 160 is provided similar to listener 130 described above . inbound queue 156 is provided to queue incoming responses from lock server 180 . jvm 170 in j2ee dispatcher process 114 may be analogous to either jvm 120 or jvm 150 . in some embodiments , the locking manager in the jvms hosted within all processes of a particular instance user a same library format to communicate with lock server 180 . thus , all server processes may include a lock manager with a jni layer in a c library or just a java library . fig2 is a fundamental modeling concept diagram of interaction within lock manager and lock server in one embodiment of the invention . the lock manager generates a request for a lock at 202 . at 204 , the request is received by the lock server . the lock server checks for the availability of the lock at 206 . in one embodiment , lock server reviews the type of lock , e . g ., exclusive or non - exclusive requested and checks the lock table , which may be stored in shared memory , to discern if the lock is available . at 208 , if the lock is available , the lock server grants the lock to the requesting process at 210 and enters the lock requested into the lock table at 212 . at 213 , the granted lock is received by requesting node &# 39 ; s lock manager and queued in the inbound queue . at 214 , a requesting thread is notified that the lock has been received . at node 215 , the thread conducts whatever transaction necessitated the lock . after the transaction is complete , the lock is released at 216 . if instead at node 208 , the lock was not available , the timeout parameter within the call may be checked if wait on locking is supported . if wait on locking is not supported the timeout parameter can be thought of as zero . at node 220 , if the timeout parameter has not been exceeded , the lock request is entered into the lock request queue and continues to wait for lock availability until the lock is available or the timeout parameter is exceeded . when a timeout parameter is exceeded , an exception is sent to the requesting lock manager at 224 and the lock entry is cleared from the lock request queue at 226 . at 227 , the exception is received in the inbound queue of the requesting lock manager . at 228 , requesting thread is notified of the exception . when a process becomes inactive e . g ., crashes or shuts down , asynchronis with the general lock request sequencing lock server receive a notification that a process has become inactive at 230 . this message may be provided by the message server , as noted above . responsive to such notification , the lock server checks the lock table for lock entries associated with the now inactive process at 232 . at node 234 , if there is no lock registered for inactive process , no action is taken at 236 . the release lock request ( sent at 216 ) is received by a lock server at node 238 . alternatively , if lock entries have been identified for an inactive process the lock server internally generates a release lock event . in either case , lock server clears a corresponding entry or entries the lock table at 240 . the lock for that data is then available to the next requesting process . elements of the present invention may also be provided as a machine - readable medium for storing the machine - executable instructions . the machine - readable medium may include , but is not limited to , flash memory , optical disks , cd - roms , dvd roms , rams , eproms , eeproms , magnetic or optical cards , propagation media or other type of machine - readable media suitable for storing electronic instructions . for example , the present invention may be downloaded as a computer program which may be transferred from a remote computer ( e . g ., a server ) to a requesting computer ( e . g ., a client ) by way of data signals embodied in a carrier wave or other propagation medium via a communication link ( e . g ., a modem or network connection ). in the foregoing specification , the invention has been described with reference to specific embodiments thereof . it will , however , be evident that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims . the specification and drawings are , accordingly , to be regarded in an illustrative rather than a restrictive sense .