Directory access method

[0002] 1. Field of the Invention

[0003] The present invention relates to a method of reliably accessing data on a directory server in a network.

[0004] 2. Description of the Related Art

[0005] Electronic mail systems are becoming more and more popular as means for realizing smooth communications within an enterprise and between enterprises by transmitting and receiving documents created on information processing apparatus such as personal computers (PC), workstations (WS) and so on through a network such as LAN (Local Area Network).

[0006] A current electronic mail system uses a unique identifier referred to as a “mail address” as the mail destination for each user. A user is assumed to know the mail address of a recipient before transmitting a mail, so that when the user sends a mail to a certain person for the first time, the user should inquire the person for his or her mail address beforehand by an appropriate means such as a telephone, thus involving an extra effort.

[0007] As a means for solving the problem mentioned above, a directory service has been provided as represented by X.500 (ISO9594) which is a recommendation of CCITT, or the like. The directory service may be utilized as an electronic address book in an electronic mail system.

[0008] A directory service conforming to X.500 has a data model which is hierarchically managed as a tree structure (directory tree). A directory entry is located at a position corresponding to a leaf of the tree. Each entry is uniquely identified by a name including hierarchical information (DN: Distinguished Name), and can store, in addition to a mail address of a user, various information such as full name, telephone number, FAX number, picture and so on of the user as attributes.

[0009] In addition, X.500 employs a client-server type distributed system architecture, and defines DAP (Directory Access Protocol) which complies with a seven-layer structure of OSI (Open Systems Interconnection) as a communication protocol between information processing units serving as clients and a server.

[0010] On the other hand, the IETF (Internet Engineering Task Force), which is a standardization organization in the Internet, has standardized “LDAP: Lightweight Directory Access Protocol (RFC1777)” as a protocol between clients and a server on TCP/IP. This protocol is also described in “Lightweight Directory Access Protocol (V3)”, M. Wahl et al. RFC2251, December 1997. The user may access a directory server of X.500 from an application program (hereinafter abbreviated as “AP”) on a client through a network such as LAN, in accordance with LDAP, for searching for desired information such as the mail address of a user or the like.

[0011] FIG. 15 shows a part of an LDAP access request defined as RFC1777, which is described using ASN.1 (Abstract Syntax Notation One) defined as ISO8824.

[0012] Referring specifically to FIG. 15, Search 24 is a request for searching directory entries; Add 25 is a request for adding an entry; Delete 26 is a request for deleting an entry; and Modify 27 is a request for changing an attribute value in an entry. Other than the requests shown in FIG. 15, various access requests have been defined by RFC1777 as protocol elements, including Bind for starting a connection, Unbind for closing a connection, ModifyRDN for changing the name of an entry, Compare for comparing a certain attribute value between entries, and so on.

[0013] The directory server receives the access requests shown in FIG. 15, issued by a client, and access a database (hereinafter abbreviated as DB) which stores information on each directory entry. When an access request involves a search operation such as Search 24 or the like, the directory server searches the DB for an entry or entries meeting specified conditions, extracts the entry or entries from the DB, and returns the extracted entry or entries to the client. On the other hand, when an access request involves a modify operation such as Add 25, Delete 26, Modify 27 or the like, the directory server modifies associated directory information on the DB and returns the result to the client.

[0014] According to the conventional directory access method mentioned above, when the directory server receives a modify request, the directory server modifies associated directory information on the DB and simultaneously validates the modified information, so that the following problems arise.

[0015] For example, assume that the processing is suddenly interrupted due to power interruption, user's erroneous manipulations, or erroneous operations of the information processing unit itself or a program, while an AP is successively updating a plurality of directory information items. Within a sequence of directory information items in course of the modification, only those which have reached the directory server are reflected to the DB.

[0016] A similar problem may also arise by an interruption of a work by the user. Specifically, when a sequence of meaningful processing is interrupted, the directory information looses the consistency, and it is difficult to eliminate the inconsistency once introduced into the DB. In addition, the conventional method only has a poor exclusive control capability.

[0017] It is therefore an object of the present invention to provide a directory access method which is capable of guaranteeing the consistency of directory information even if an inadvertent interruption due to a fault in a system or the like, an intended interruption made by a user or an AP, or the like occurs during the execution of a sequence of directory operations, or during simultaneous accesses from a plurality of APs.

[0018] To achieve the above object, the directory access method according to the present invention collectively processes a sequence of meaningful access requests as a logical work unit (transaction). According to a directory service implementing the directory access method of the present invention, a client issues an access request to a directory server either in a non-transaction phase or in a transaction phase. In the non-transaction phase, issued access requests are individually reflected to a database as before. The non-transaction phase thus provides the compatibility with conventional systems. In the transaction phase, on the other hand, a sequence of issued access requests are collectively reflected to the database as a single transaction. The client can bidirectionally transit between both the phases in accordance with the contents of processing. When the client transits to the transaction phase and issues a sequence of access requests, the consistency is guaranteed for a plurality of directory information items to be processed by the access requests.

[0019] To implement the directory access method according to the present invention, a directory server comprises a database for storing directory information; a non-transaction unit for processing individual access requests as different transactions; a transaction processing unit for processing a sequence of access requests as a single transaction; a phase management table for storing a processing phase for each connection with a client; and a phase management unit for passing a received access request to the non-transaction processing unit or to the transaction processing unit based on a stored processing phase.

[0020] In addition, the client is provided with a request for the directory server for defining transaction processing.

[0021] FIG. 1 is a block diagram illustrating the configuration of a system according to the present invention;

[0022] FIG. 2 is a block diagram illustrating the configuration of a directory server according to the present invention;

[0023] FIG. 3 illustrates a data structure for a phase management table 7;

[0024] FIG. 4 is a flow diagram for explaining directory access processing in a first embodiment;

[0025] FIG. 5 is a flow diagram for explaining non-transaction processing in first and second embodiments;

[0026] FIG. 6 is a flow diagram for explaining transaction processing in the first embodiment;

[0027] FIG. 7 is a flow diagram for explaining interruption processing in the first embodiment;

[0028] FIG. 8 is a diagram for explaining a transaction operation in a WAIT mode in the first and second embodiments;

[0029] FIG. 9 is a diagram for explaining a transaction operation in a NOWAIT mode in the first embodiment;

[0030] FIG. 10 is a diagram for explaining a basic communication sequence in the first and second embodiments;

[0031] FIG. 11 is a diagram for explaining a communication sequence for successive transactions in the first and second embodiments;

[0032] FIG. 12 is a diagram for explaining a communication sequence when an exclusive error occurs in the first embodiment;

[0033] FIG. 13 is a diagram for explaining a communication sequence when a connection is closed in the first and second embodiments;

[0034] FIG. 14 is a diagram for explaining state transitions in the first embodiment;

[0035] FIG. 15 is a list for explaining communication protocol elements related to search and modify;

[0036] FIG. 16 is a list for explaining a communication protocol element related to an extended operation;

[0037] FIG. 17 is a list for explaining communication protocol elements related to a transaction operation;

[0038] FIG. 18 is a flow diagram for explaining directory access processing in the second embodiment;

[0039] FIG. 19 is a flow diagram for explaining transaction processing in the second embodiment;

[0040] FIG. 20 is a flow diagram for explaining a transaction operation in a NOWAIT mode in the second embodiment;

[0041] FIG. 21 is a diagram for explaining a communication sequence when an exclusive error occurs in the second embodiment; and

[0042] FIG. 22 is a diagram for explaining state transitions in the second embodiment.

[0043] (1) First Embodiment

[0044] A first embodiment of the present invention will hereinafter be described with reference to the accompanying drawings. In the following, the same parts in various figures are designated the same reference numerals.

[0045] FIG. 1 illustrates an exemplary configuration of a system in which a directory server 1 and a plurality of clients 2 are connected through a network 10 such as LAN. The directory server 1 is connected to a DB 6 as a means for storing and managing directory information.

[0046] The directory server 1 comprises a communication control unit 3 for executing communication processing with the clients 2; a protocol analysis unit 4 for receiving a request for accessing directory information and analyzing the contents of the access request; a non-transaction processing unit 5 for processing individual access requests as different transactions as before; a transaction processing unit 9 for processing a sequence of access requests as a single transaction; a phase management table 7 for storing a processing phase for each connection with a client 2; and a phase management unit 8 for passing an received access request to the non-transaction processing unit 5 or to the transaction processing unit 9 based on the processing phase.

[0047] The directory server 1 may be implemented by a personal computer or a workstation which has a CPU (processor), a memory and a communication port. The above-mentioned units may be in the form of software executed by the CPU, and the table is placed on the memory (described later in greater detail).

[0048] The DB 6 may be, for example, a DB management system having transaction capabilities such as a relational DB management system, an object-oriented DB management system and so on available on the market, for storing and managing information on each directory entry. The directory server 1 and the DB 6 often share the same hardware portions, and transmit and receive information therebetween through a means such as interprocess communication. The DB 6 is not limited to a DB management system as mentioned above but may be a DB package including index and search functions such as hash, B-tree and so on. As representative DB packages, dbm of UNIX, Berkeley DB and so on may be presented. Since such a DB package operates as a portion of an AP, the directory server 1 may access the DB 6 using a means such as a function call instead of the interprocess communication.

[0049] In the following, the first embodiment is explained in connection with a relational DB management system for managing data in the form of a table composed of rows and columns, as an example of the DB 6.

[0050] Generally, a relational database language (SQL) is utilized for accesses to a relational DB management system. The SQL has a SELECT statement for searching a table; an INSERT statement for adding a new row to the table; a DELETE statement for deleting a row in the table; a MODIFY statement for updating a row in the table; a COMMIT statement for validating all modify operations so far executed and terminating a transaction; a ROLLBACK statement for invalidating all modify operations so far executed and terminating a transaction; and so on.

[0051] A relational DB management system implicitly begins a transaction at the time a client is connected to the system, and treats a sequence of SQL statements until a COMMIT or ROLLBACK statement is issued as a single transaction. When a COMMIT or ROLLBACK statement is issued, subsequent SQL statements are treated as a new transaction.

[0052] Also, general-purpose relational DB management systems often include a lock function for a table or a row involved in a current operation. Generally, when a SELECT statement is used to search a table, a shared lock is applied to rows which meet conditions for the search. Rows, which are once shared locked, cannot be modified from other APs, but can be searched for. On the other hand, when a modify operation is executed through an INSERT statement or the like, a row to be modified is applied with an exclusive lock. An exclusively locked row cannot be searched or modified from other APs. It is also possible to explicitly specify which of shared lock or exclusive lock should be applied to a row to be accessed. When not specified, a shared lock is applied to rows associated with a search operation, while an exclusive lock is applied to rows associated with a modify operation, as mentioned above. Each lock is released when an associated transaction is terminated.

[0053] FIG. 2 illustrates the configuration of the directory server 1 according to the first embodiment. Parts in FIG. 2 substantially identical to those in FIG. 1 are designated the same reference numerals.

[0054] The directory server 1 comprises a central processing unit (CPU) 11; a magnetic disk 12 such as a hard disk drive; a main memory 13; a bus 14; a display 15; a keyboard 16; and a pointing device 17 such as a mouse. The magnetic disk 12 stores directory data 19 as a file. The main memory 16 stores a communication control program 3; a protocol analysis program 4; a phase management program 8; a non-transaction processing program 5; a transaction processing program 9; and DB management program 18. These programs are originally stored in the magnetic disk 12 and transferred to the main memory 16 as required and executed by the CPU 14. The main memory 16 further stores the phase management table 7. The DB 6 in FIG. 1 is composed of the DB management program 18 and the directory data 19.

[0055] Next explained is a request made by a user (directory client 2) to the directory server 1 in the directory access method according to the present invention, taking the LDAP as an example.

[0056] FIG. 16 shows a notation of an access request Extended 28 for an extended operation defined in the LDAP. Extended 28 is a request provided to allow a vendor or the like to individually extend functions, and has two parameters: requestName and requestValue. The requestName is loaded with a globally unique object identifier (OID) described in X.208 Recommendation of CCITT for uniquely identifying an extended function. The requestValue in turn is loaded with various values individually used by the extended function as an octet string. The requestValue is an option, and thus may not be loaded with any value if not required.

[0057] FIG. 17 shows an access request provided for a client in the directory access method of the first embodiment. The directory access method of the first embodiment implements, in addition to conventional requests, three functions using Extended 28 shown in FIG. 16. The three functions are begin 29 for indicating the beginning of a transaction; commit 30 for validating all operations so far executed and terminating a transaction; and rollback 31 for invalidating all operations so far executed and terminating a transaction. In FIG. 17, <begin0id>, <commit0id>, <rollback0id>, <exclusiveMode0id> are each loaded with a numerical string as an object identifier assigned to identify their respective functions. The <exclusiveMode0id> in begin 29 is used to identify two types of exclusive modes, later described.

[0058] FIG. 10 illustrates a basic communication sequence which shows, as an example, an alternation of a conventional directory access method (37, 39) and the directory access method (38, 40) of the present invention.

[0059] First, as a first phase, a client 2, after connecting to the directory server 1, issues search and modify requests. Since the server 1 has not received begin 29 for indicating the beginning of a transaction, the server 1 treats these requests as a normal operation 37 of a non-transaction phase. Specifically, the server 1 issues an SQL statement corresponding to each statement and a COMMIT statement to the DB 6, and validates data simultaneously with modification associated with each request.

[0060] Next, as a second phase, the client 2 issues begin 29 for indicating the beginning of a transaction, and then issues a plurality of modify requests. The server 1 receives begin 29, recognizes the modify requests subsequent thereto as an operation 38 in a transaction phase, and issues an SQL statement corresponding to each modify request to the DB 6. When the client 2 issues commit 30 for indicating a normal termination of the transaction at the end of the transaction phase 38, the server 1 issues a COMMIT statement to the DB 6 to validate a sequence of modified data in the transaction 38.

[0061] Further, as a third phase, when the client 2 issues a plurality of modify requests, the server 1 treats these modify requests as a normal operation 39 in a non-transaction phase, issues an SQL statement corresponding to each request and a COMMIT statement to the DB 6, and validates data simultaneously with modification associated with each request.

[0062] Finally, as a fourth phase, when the client 2 issues a plurality of modify requests after issuing begin 29 for indicating the beginning of a transaction, the server 1 recognizes these modify requests as an operation 40 in a transaction phase, and issues an SQL statement corresponding to each modify request to the DB 6. When the client 2 issues rollback 31 for indicating an abnormal termination of the transaction at the end of the transaction phase 40, the server 1 issues a ROLLBACK statement to the DB 6 to force the client 2 to discard a sequence of modified data in the transaction 40.

[0063] As described above, the AP on the client 2 can bidirectionally transit between the non-transaction phase and the transaction phase by explicitly issuing begin 29, and commit 30 or rollback 31. The server 1 treats at least one or more requests received between begin 29 and commit 30 or rollback 31, within all access requests, as a single transaction, and individually processes the remaining access requests as before.

[0064] In an alternative, there may be a case where a plurality of transaction operations be desirably executed in succession, rather than alternately repeating a non-transaction operation and a transaction operation as described above. A communication sequence for this case is illustrated in FIG. 11.

[0065] The client 2 issues begin 29 for indicating the beginning of a transaction, and then issues a plurality of modify requests. The server 1 receives begin 29, recognizes the modify requests subsequent thereto as an operation 41 in a transaction phase, and issues an SQL statement corresponding to each modify request to the DB 6. When the client 2 issues begin 29 for indicating the beginning of a transaction at the end of the transaction phase 41, the server 1 recognizes the beginning of a new transaction, validates a sequence of modified data in the transaction 41 by issuing a COMMIT statement to the DB 6, and subsequently transits to a new transaction phase 42.

[0066] As described above, begin 29 serves not only as a normal termination indication for a current transaction but also as a indication for the beginning of the next transaction, when issued during a transaction phase.

[0067] On the other hand, if the client 2 fails during a transaction, the server 1 or the DB 6, which may detect the failure by a means such as time monitoring using a timer or the like, discards directory information modified during the transaction, and restores information in the DB 6 to the state before the transaction. Also, as illustrated in FIG. 13, when the server 1 receives unbind which is an access request for closing a connection with the directory service during a transaction 44, the server 1 similarly issues a ROLLBACK statement to the DB 6 to discard a sequence of modified data during the transaction 44, and restore information in the DB 6 to the state before the transaction 44.

[0068] Next, a lock function during a transaction will be explained.

[0069] As mentioned above, general-purpose relational DB management systems often include a lock function for a table or a row which is being operated. For example, when an AP attempts to access data previously locked by another AP, it is also possible to specify, at the time of issuing an SQL statement, whether the AP is placed into a wait state until the data is released from the locking or an exclusive error is immediately returned.

[0070] The directory access method of the first embodiment, thus, utilizes the lock function provided in the DB 6 to implement the following two types of exclusive modes during a transaction.

[0071] The operation of a WAIT mode, i.e., a first exclusive mode (FIG. 8) and the operation of a NOWAIT mode, i.e., a second exclusive mode (FIG. 9) will be explained below with a specific example in which the server 1 is accessed simultaneously by an AP 46 on a client attempting to modify a directory entry B as a non-transaction, similarly to the prior art, and an AP 45 on another client attempting to modify entries A and B as a transaction.

[0072] First, the operation in the WAIT mode is shown with reference to FIG. 8. The WAIT mode brings an AP into a wait state when a directory entry accessed by the AP has been locked by another AP.

[0073] The AP 45 issues begin 29 having an object identifier, as a parameter, assigned to the WAIT mode in the form of <exclusiveMode0id>, and then modifies an entry A. Subsequently, when the AP 45 attempts to modify an entry B, the AP 45 is brought into a processing wait state since the entry B is being modified by an AP 46. The request issued by the AP 45 to modify the entry B is executed after the AP 46 has completed the modification to the entry B.

[0074] Next, the operation in the NOWAIT mode is shown with reference to FIG. 9. The NOWAIT mode returns the control to an AP as an exclusive error when a directory entry accessed by the AP has been locked by another AP. FIG. 12 illustrates a communication sequence of a transaction operation in the NOWAIT mode.

[0075] In FIG. 9, the AP 45 issues begin 29 having an object identifier, as a parameter, assigned to the NOWAIT mode in the form of <exclusiveMode0id>, and then modifies an entry A. Subsequently, when the AP 45 attempts to modify an entry B, an exclusive error is returned as an error code, and the control is returned to the AP 45 since the entry B is being modified by the AP 46. As illustrated in FIG. 12, information on the entry A modified by the AP 45 during a transaction 43 is implicitly discarded at this time. The AP 45, upon detecting the exclusive error, explicitly issues rollback 31 for indicating an abnormal termination of the transaction to the server 1.

[0076] The transaction operation in the WAIT mode illustrated in FIG. 8 can be processed without taking into account whether or not an directory entry to be accessed has been locked by another AP, so that the AP can be simplified. However, if a plurality of APs modify a plurality of entries in the opposite order, a dead lock phenomenon is likely to occur. In contract, the transaction operation in the NOWAIT mode illustrated in FIG. 9, although requiring the processing for the exclusive error, is free from the possibility of dead lock. The directory access method according to the first embodiment enables an AP to select the exclusive mode during a transaction operation depending on particular applications or the like.

[0077] FIG. 14 illustrates a state transition diagram for the directory server 1 which implements the directory access method of the first embodiment. Ellipses indicate states possibly taken by the directory server 1, while rectangles indicate processing performed by the directory server 1. Arrows represent state transitions, and each character string added to each arrow represents an event. Specifically, an capital letter string added to each arrow represents an response from the DB 6, while a small letter character string added to each arrow indicates a request from the client 2. An arrow exiting a rectangle is validated upon termination of the processing indicated in the rectangle. The state transition diagram includes a request wait state 47 in a non-transaction phase and request wait states 48, 49 in a transaction phase.

[0078] In the non-transaction phase 47, when the server 1 receives a search request 24 and modify requests 25, 26, 27 in accordance with the LDAP illustrated in FIG. 15 from a client 2, the server 1 generates SQL statements which meet the respective requests.

[0079] For example, the server 1 translates a search request (Search) of the LDAP into a SELECT statement of the SQL; an addition request (Add) into an INSERT statement; a deletion request (Delete) into a DELETE statement; and a modification request (Modify) into an UPDATE statement, respectively. Parameters associated with the LDAP requests are also translated into SQL parameters. Depending on certain relationship between the LDAP and SQL parameters, one request of the LDAP may be translated into a plurality of SQL statements. Also, each SQL statement is followed by processing for checking the result of executing the statement, i.e., the result of an access to the DB 6.

[0080] The server 1 completes a transaction by issuing a COMMIT statement to the DB 6 when an access to the DB 6 has been normally terminated, or by issuing a ROLLBACK statement when an access to the DB 6 has resulted in an error, and then returns again to the non-transaction phase 47. The server 1, upon receipt of begin 29, transits to the transaction phase 48 to begin a transaction.

[0081] In the transaction phase 48, when the server 1 receives a search request 24 and modify requests 25, 26, 27 illustrated in FIG. 15 from a client 2, the server 1 generates SQL statements which meet the respective requests, as is the case of the non-transaction phase, accesses the DB 6, and then returns again to the transaction phase 48. Next, when the server 1 receives commit 30 or rollback 31 shown in FIG. 17, the server 1 completes a transaction by issuing a COMMIT statement or a ROLLBACK statement to the DB 6, respectively, and transits to the non-transaction phase 47. Also, when the server 1 receives begin 29, the server 1 normally terminates a transaction by issuing a COMMIT statement to the DB 6, and returns to the transaction phase 48 to begin another transaction. On the other hand, if an exclusive error occurs in an access to the DB 6 during a transaction in the NOWAIT mode, the server 1 abnormally terminates the transaction by issuing a ROLLBACK statement to the DB 6, and then transits to a transaction phase 49.

[0082] In the transaction phase 49, the server 1 transits to the non-transaction phase 47 upon receipt of rollback 31.

[0083] In the following, the processing performed by the directory server 1 will be explained.

[0084] FIG. 3 illustrates the structure of a phase management table 7 for storing information on processing phases for each connection with the client 2. As illustrated, the phase management table 7 has a matrix structure.

[0085] A client 2 delivers each of the access requests illustrated in FIGS. 15, 16, 17 on TCP/IP. A communication packet of TCP/IP includes an IP address and a socket number of an originator or a client 2.

[0086] A matrix in the phase management table 7 stores information related to TCP/IP connection with an AP on the client 2, and has matrix elements such as a storage field 20 for storing the IP address of the client 2; a storage field 21 for a socket number; a storage field 22 for storing a current phase; and a storage field 23 for storing the exclusive mode. The phase storage field 22 is set to “1” during a non-transaction phase 47, and to “2” or “3” during a transaction phase 48 or 49, respectively. The value contained in this phase storage field 22 matches the state indicated in an associated ellipse in FIG. 14. The exclusive mode storage field 23 is set to a value of <exclusiveMode0id> which is a parameter of begin 29.

[0087] When the protocol analysis unit 4 receives a Bind request for starting a connection, the phase management unit 8 newly reserves a matrix in the phase management table 7, stores the IP address and the socket number of the client 2 included in the request in the IP address storage field 20 and the socket number storage field 21, respectively, and then sets the phase storage field 22 to “1”, and initializes the exclusive mode storage field 23 to “NULL” indicative of a blank character string.

[0088] Also, when the protocol analysis unit 4 receives an Unbind request for closing a connection, the phase management unit 8 searches the phase management table 7, and deletes a matrix which stores the same values as the IP address and the socket number of the client 2. As illustrated in FIG. 13, if the protocol analysis unit 4 receives an Unbind request during a transaction phase, the transaction processing unit 9 issues a ROLLBACK statement to the DB 6 to discard the transaction prior to the deletion of the matrix.

[0089] FIG. 4 illustrates the processing of the server 1 upon receipt of a request other than a Bind request. Referring specifically to FIG. 4, when the communication control unit 3 receives a request from a client 2 (S401), the protocol analysis unit 4 analyzes the request, and notifies the phase management unit 8 of the contents of a header portion in a request packet (S402). The phase management unit 8, upon receiving the notification, searches the phase management table 7 for a matrix which stores the same values as the IP address and the socket number of the client 2 included in the request, and confirms the value in the phase storage field 22 (S403 or S405). The phase management unit 8 executes non-transaction processing (S404) when the value stored in the phase storage field 22 is “1”, transaction processing (S406) when “2”, and interruption processing (S407) when “3”.

[0090] FIG. 5 is a flow chart illustrating the non-transaction processing (S404) in FIG. 4.

[0091] In the non-transaction phase 47, the phase management unit 8 confirms the contents of an access request notified from the protocol analysis unit 4 (S501), and requests the non-transaction processing unit 5 to undertake the processing when the access request does not involve any of the transaction requests shown in FIG. 17, i.e., when the access request is any of those shown in FIG. 15. The non-transaction processing unit 5, upon receipt of the request, generates SQL statements such as SELECT, INSERT and so on which satisfy the request (S502), issues these SQL statements to the DB 6 (S503), and waits for the processing to terminate (S504). The DB 6 searches for or modifies directory data in accordance with the received SQL statements, and returns the processing result to the non-transaction processing unit 5. When the search or modify processing in the DB 6 is normally terminated at S504, the non-transaction processing unit 5 normally terminates the transaction by issuing a COMMIT statement to the DB 6 (S505). On the other hand, if the search or modify processing fails in the DB 6, the non-transaction processing unit 5 abnormally terminates the transaction by issuing a ROLLBACK statement to the DB 6 (S506). Finally, the phase management unit 8 returns the processing result of the access request to the client 2 through the communication control unit 3 (S507).

[0092] At S501, if the request notified from the protocol analysis unit 4 involves any of the transaction requests shown in FIG. 17, the processing flow proceeds to S508. If the request is begin 29 at S508, the phase management unit 8 sets “2” (transaction processing) in the phase storage field 22 in the phase management table 7 in order to transit to the transaction phase 48 (S509), and registers the value of <exclusiveMode0id>, which is a parameter of begin 29, in the exclusive mode storage field 23 (S510). Then, the phase management table 8 returns a normal termination to the client 2 as the processing result (S507). On the other hand, if the request is other than begin 29 at S508, the phase management unit 8 regards the request as a sequence error, and therefore returns an operation error to the client 2 as the processing result (S511).

[0093] FIG. 6 is a flow chart illustrating the transaction processing (S406) in FIG. 4.

[0094] In the transaction phase 48, the phase management unit 8 confirms the contents of a request notified from the protocol analysis unit 4 (S601), and notifies the transaction processing unit 9 of the contents of the request and the value in the exclusive mode storage field 23 in the phase management table 7 and requests the transaction processing unit 9 to undertake the processing when the access request does not involve any of the transaction requests shown in FIG. 17, i.e., when the access request is any of those shown in FIG. 15. The transaction processing unit 9, upon receipt of the request, generates SQL statements such as SELECT, INSERT and so on which satisfy the request (S602), and issues these SQL statements to the DB 6 (S603). In this event, the transaction processing unit 9 confirms the notified exclusive mode, and instructs the DB 6, when in the WAIT mode, to wait until a lock is released if the access request contends with that of another AP. On the other hand, if in the NOWAIT mode, the transaction processing unit 9 instructs the DB 6 to immediately return the control to the requesting AP as an exclusive error if the access request contends with that of another AP. Simultaneously, the transaction processing unit 9 instructs the DB 6 to apply an exclusive lock if the received access request is Search 24. The DB 6 searches for or modifies directory data in accordance with the received SQL statements, and returns the processing result. When the search or modify processing is normally terminated in the DB 6 at S604, the phase management unit 8 returns a normal termination to the client 2 through the communication control unit 3 as the processing result of the access request (S609). On the other hand, if the search or modify processing fails in the DB 6, and if the failure is not caused by an exclusive error (S605), the phase management unit 8 returns a processing failure to the client 2 as a result (S609). On the other hand, if the failure is caused by an exclusive error at S605, the transaction processing unit 9 abnormally terminates the transaction by issuing a ROLLBACK statement to the DB 6 (S606). Next, the phase management unit 8 sets “3” in the phase storage field 22 in the phase management table 7 (S607) in order to transit to a transaction phase 49, and then returns an exclusive error to the client as the processing result (S608).

[0095] Back to S601, if a request notified from the protocol analysis unit 4 is any of the transaction requests shown in FIG. 17, the processing flow proceeds to S610. If the request is other than rollback 31 at S610, i.e., if the request is begin 29 or commit 30, the phase management unit 8 requests the transaction processing unit 9 to issue a COMMIT statement in order to normally terminate the transaction (S611). Further, if the request is commit 30 (S612), the phase management unit 8 sets “1” in the phase storage field 22 in the phase management table 7 in order to transit to the non-transaction phase 47 (S613), and registers “NULL” indicative of a blank character string in the exclusive mode storage field 23 (S614), and then returns the result of the transaction processing to the client 2 (S615). On the other hand, if the request is begin 29 at S612, the phase management unit 8 registers the value of <exclusiveMode0id>, which is a parameter of begin 29, in the exclusive mode storage field 23 (S617), and the processing flow thereafter proceeds to S615. Further, if the request is rollback 31 at S610, the phase management unit 8 requests the transaction processing unit 9 to issue a ROLLBACK statement (S616) in order to abnormally terminate the transaction, followed by the processing flow proceeding to S613.

[0096] FIG. 7 is a flow chart illustrating the interruption processing (S407) in FIG. 4.

[0097] In the transaction phase 49, when a request notified from the protocol analysis unit 4 is rollback 31 (S701), the phase management unit 8 sets “1” in the phase storage field 22 in the phase management table 7 in order to transit to the non-transaction phase 47 (S702), registers “NULL” indicative of a blank character string in the exclusive mode storage field 23 (S703), and then returns the result of the transaction processing to the client 2 (S704). On the other hand, if the request is other than rollback 31 at S701, the phase management unit 8 assumes a sequence error, and returns an operation error to the client 2 as the processing result (S705).

[0098] (2) Second Embodiment

[0099] Next, a second embodiment of the present invention will be described. The second embodiment differs from the first embodiment in the processing for the exclusive error of SQL.

[0100] According to the first embodiment, if an exclusive error is produced because a directory entry to be accessed by an AP has already been locked by another AP in a transaction phase of the NOWAIT mode as illustrated in FIG. 12, the transaction 43 is automatically terminated as abnormal. This is a specification due to functional limitations of the DB 6. Many of general-purpose relational database management systems cannot continue a transaction when an exclusive error occurs due to such multiple lock, so that the transaction should be explicitly concluded with a ROLLBACK statement.

[0101] The second embodiment provides a directory access method which uses a DB 6 that can continue a transaction even if an exclusive error occurs due to multiple lock.

[0102] In the following, description will be focused only on differences between the second embodiment and the first embodiment.

[0103] FIG. 20 illustrates the operation in a NOWAIT mode, and FIG. 21 illustrates a communication sequence. These figures correspond to FIGS. 9, 12 in the first embodiment, respectively.

[0104] When an AP 45 attempts to modify an entry B during transaction processing in the NOWAIT mode, an exclusive error is returned as an error code, and the control is returned to the AP 45 because the entry B is being modified by an AP 46. The AP 45, which implements the second embodiment, retries to modify the entry B, for example, after the lapse of a fixed period, if the AP 45 detects the exclusive error. The server 1 processes a request issued by the AP 45 to modify the entry B, if the AP 46 has terminated the modification to the entry B and the entry B has been released from the lock.

[0105] According to the first embodiment, when an exclusive error occurs due to multiple lock, each transaction should be retried. In contrast, according to the directory access method of the second embodiment, a retry is only required to modify the entry B without discarding the previously performed processing for updating an entry A, thus improving the operability from a viewpoint of the AP.

[0106] FIG. 22 is a state transition diagram for the directory server 1 which implements the directory access method of the second embodiment, and corresponds to FIG. 14 in the first embodiment. In the second embodiment, the transaction phase 49 is not required.

[0107] In the transaction phase 48, upon receipt of the search request 24 and the modify requests 25, 26, 27 shown in FIG. 15, the server 1 generates SQL statements which meet the requests, accesses the DB 6, and again returns to the transaction phase 48. If an exclusive error occurs while the DB 6 is being accessed during a transaction in the NOWAIT mode, the server 1 returns to the transaction phase 48.

[0108] In the following, the processing in the directory access method of the second embodiment will be explained with reference to FIGS. 18, 19.

[0109] FIGS. 18, 19 are flow charts illustrating the operation of the server 1 upon receipt of a request other than a Bind request, and correspond to FIGS. 4, 6 in the first embodiment, respectively.

[0110] In FIG. 18, the phase management unit 8 executes the non-transaction processing (S404) when the value stored in the phase storage field 22 is “1” and the transaction processing (S406) when “2”.

[0111] At S605 in FIG. 19, if search or modify processing fails in the DB 6 due to an exclusive error, the exclusive error is returned to the client 2 as the processing result (S608). The client 2 retries the processing after the lapse of a fixed time.

[0112] In the second embodiment, a transaction can be continued even if an exclusive error occurs due to multiple lock, thereby improving the operability.

[0113] (3) Modifications

[0114] To prepare for suddenly interrupted processing due to power interruption, user's erroneous manipulations, erroneous operations of the information processing unit itself or a program, and so on while an AP is successively updating a plurality of directory information items, the server 1 may be provided with a client monitoring means and a timer monitoring means (not shown) to detect any abnormality in the client 2. The timer monitoring means may be provided in the DB 6 instead of the server 1. In this case, the DB 6 notifies the server 1 of abnormality in the client 2, so that the server 1 can perform similar processing.

[0115] When the server 1 detects abnormality in the client 2 while a transaction is being processed, the transaction processing unit 9 issues a ROLLBACK statement to the DB 6 to discard the transaction. Then, the phase management unit 8 searches the phase management table 7 for a matrix having stored therein the same values as the IP address and the socket number of the client 2, and deletes this matrix.

[0116] Also, as illustrated in FIG. 1, the directory service in the respective embodiments has a three-layer structure including the client 2, the directory server 1 and the DB 6. It should be understood that this structure is employed to facilitate the explanation of transmission and reception of a sequence between the respective layers. The DB 6 for storing directory information is indispensable for the server 1. Actually, the directory server 1 may contain the DB 6 as one functional element thereof, in which case similar effects can be produced.

[0117] Further, as illustrated in FIGS. 5, 6 and FIG. 19, the non-transaction processing unit 5 and the transaction processing unit 9 have some operations which include common processing. Therefore, the non-transaction processing unit 5 and the transaction processing unit 9 may be integrated into a single unit. In this case, when the phase management unit 8 passes an access request from the client 2 to the integrated unit, the phase management unit 8 notifies the integrated unit whether a current processing phase is a non-transaction phase or a transaction phase. Alternatively, the integrated unit itself may reference the phase management table 7 so as to determine whether an access request passed from the phase management unit 8 should be processed in a non-transaction phase or a transaction phase.

[0118] The foregoing embodiments have been described on the assumption that one application will never process two or more transactions simultaneously. However, a plurality of transactions can be processed simultaneously by exchanging information for identifying transactions between a client and a server, adding an entry for identifying such information in the phase management table, and managing the information.

[0119] Also, while the foregoing embodiments have been described for a specific example in which the LDAP and SQL are utilized, the present invention may also utilize any protocol and database operation language as long as they have similar functionalities.