JP6902580B2 - Systems and methods for providing distributed caching in transaction processing environments - Google Patents

Description

Field of Invention:
Embodiments of the invention generally relate to application server and cloud environments, especially systems and methods for providing distributed caching in transaction processing environments.

background:
In transaction processing environments such as Tuxedo® server environments, distributed caching systems that cache user-related or application data to improve performance can be challenging. This is because multiple data types can be used to send data between the client and server processes, which can lead to different customers choosing different caching solutions. These are areas that the embodiments of the present invention are intended to address.

Overview:
According to one embodiment, systems and methods for providing distributed caching in a transaction processing environment are described herein. The top layer can expose and use the application programming interface (API) by caching the client to interact with the caching system, with multiple buffer types and each buffer type. One or more callback functions can be registered for. A common caching layer can support a common data structure, and when it receives a caching request from the top layer, it uses its callback functionality to provide data in common with the particular buffer type associated with the caching request. Conversions can be made to and from the structure. A common caching layer can define a set of common APIs to provide caching-related APIs, as well as common behavior for multiple implementations such as serialization / deserialization of key and value data. Can be defined. The provider switch and associated APIs can be used to load specific implementations of the provider switch from the implementation layer. The provider switch may include pointers to the caching behavior provided by a particular caching provider. The configuration file can be used to specify the data coding and which caching provider to use for the caching system.

According to one embodiment, systems and methods for supporting data serialization used by distributed caching systems are described herein. Data serialization systems can contain common data structures. Common data structures can be used to store serialized streams / bytes of multiple data types. The data structure may include a header that contains information that describes the cache setter's architecture. When retrieving cached data for use on a different architecture, the architecture information in the header can be used to transform the data for use on that different architecture. If the cached data is retrieved on the same architecture, the cached data can be used without conversion. The data structure may additionally include a body with variable length to allow efficient use of memory, version information about backward compatibility, and fields for optional features for expansion.

According to one embodiment, systems and methods for integrating a distributed in-memory data grid (eg, Coherence) into a distributed caching system as a caching provider are described herein. The proxy server in the distributed caching system can act as a client for the distributed in-memory data grid and can receive caching requests forwarded from the IDC client. At startup, the proxy server loads the configuration file that defines the caching system cache and the map that it caches in the distributed in-memory data grid cache, and advertises the service using the name of the caching system cache. be able to. Upon receiving a caching request from a caching client that specifies the requested service, the proxy server can determine the corresponding cache in the distributed in-memory data grid for access based on the requested service. ..

According to one embodiment, a system and method for caching the results returned from a service using a distributed caching system in a transaction processing environment is described herein. The configuration file contains a caching section that contains an entry that describes which cache should be used to cache the results returned by the service and how to generate the key used to identify the cached results. Can include. When a request for a service is received from a client, the application server core in the transaction processing environment determines if the associated cached data is in the cache identified by the key generated using the configuration file. can do. If present, the application server core can return the cached data directly instead of calling the service. In other cases, the application server core can call the service and use the generated key to cache the data in the cache specified by the configuration file and return the result to the client.

It is a figure which shows the system for providing the distributed caching in the transaction processing environment according to one Embodiment. FIG. 5 further illustrates a system for providing distributed caching used in a transaction processing environment according to an embodiment. It is a detailed class diagram which shows the caching API according to one Embodiment. It is a figure which shows the method for providing the distributed caching used in the transaction processing environment according to one Embodiment. It is a figure which shows the exemplary typed buffer according to one Embodiment. It is a figure which shows the system for supporting the data serialization used by the distributed caching system according to one Embodiment. It is a figure which shows the method for supporting the data serialization used by the distributed caching system according to one Embodiment. It is a figure which shows the system for integrating the distributed in-memory data grid into the distributed caching system as a caching provider according to one Embodiment. FIG. 5 further illustrates a system for integrating a distributed in-memory data grid into a distributed caching system as a caching provider according to one embodiment. It is a figure which shows the method for integrating the distributed in-memory data grid into the distributed caching system as a caching provider according to one Embodiment. It is a figure which shows the system for caching the result returned from the service by using the distributed caching system in the transaction processing environment according to one Embodiment. It is a figure which shows the method for caching the result returned from the service by using the distributed caching system in the transaction processing environment according to one Embodiment.

Detailed explanation:
In a transaction processing environment (eg, a Tuxedo server environment), a buffer needs to be allocated before a message can be sent from one process to another. Complex applications in such an environment can be installed on heterogeneous systems that communicate over multiple networks using a variety of protocols. Therefore, different types of buffers are needed, and each buffer type requires different routines for initializing, sending, receiving, and encoding and decoding data.

Typically, when a user (for example, an application developer) caches a typed buffer in a distributed caching system for better performance, the user must write code customized for a particular typed buffer. There is. In addition, if a different caching provider is used after the application development is complete, additional code changes will be required to accommodate the changes in the caching provider.

Distributed Caching Systems According to one embodiment, systems and methods for providing distributed caching in a transaction processing environment are described herein. The top layer can expose and use application programming interfaces (APIs) by caching clients to interact with the caching system, with multiple buffer types and one or more for each buffer type. You can register the callback function of. A common caching layer can support a common data structure, and when it receives a caching request from the top layer, it uses its callback functionality to provide data in common with the particular buffer type associated with the caching request. Conversions can be made to and from the structure. A common caching layer defines a set of common APIs to provide caching-related APIs, and defines common behavior for multiple implementations such as serialization / deserialization of key and value data. Can be done. The provider switch and associated APIs can be used to load specific implementations of the provider switch from the implementation layer. The provider switch may include pointers to the caching behavior provided by a particular caching provider. The configuration file can be used to specify the data coding and which caching provider to use for the caching system.

A layered caching system can separate the user from the underlying caching provider, which makes the system easier to use and scale.

For example, a caching system can be used with multiple caching providers to cache multiple data types without the need to modify the user's application. Users use the same set of APIs regardless of what buffer type the developer needs to cache and which caching provider should be configured for that caching system. Can perform caching operations.

According to one embodiment, the distributed caching system can reduce the number of accesses and updates, can cache multiple types of buffers, each identified by a key, replication access, non-replication access, Can provide local and remote access.

FIG. 1 shows a system for providing distributed caching used in a transaction processing environment according to an embodiment.

As shown in FIG. 1, the distributed caching system 105 has a caching client (eg, a Tuxedo client or server) 101 to store data in the cache (106) or retrieve data from the cache (107). It may be provided in the transaction processing system (eg, Tuxedo server environment) 100 used by.

As further shown in FIG. 1, a distributed caching system includes multiple layers, such as buffer-based distributed caching (BDC) layer 109, common distributed caching (CDC). ) Layer 125, implementation of distributed caching (IDC) layer 141, and dependent third-party vendor (DTV) layer 149. The configuration file 103 includes a BDC layer and a CD.
It can be used to define the behavior of the C layer and the IDC layer.

According to one embodiment, the BCD layer is the top layer for caching clients and can handle multiple typed buffers, after converting the typed buffer to a common typed buffer supported by the CDC. Caching requirements can be transferred from the caching client to the CDC layer. The main function of the top layer is the serialization and deserialization of various typed buffers.

As further shown in FIG. 1, the BDC layer can expose a set of external APIs 121 used by the caching client to communicate with the caching system. For example, an external API can be used directly in an application to cache or retrieve data from the cache.

Table 1 below shows a list of exemplary interfaces for external APIs according to one embodiment.

According to one embodiment, as shown in Table 1, the external API gets a handle to the cache, puts a buffer in the cache, associates the buffer with a key, and the application removes the buffer from the cache and retrieves it. It may include the method to be used.

For example, the user can use the method "tpgetcache" to obtain the Tuxedo cache handle. The method parameter "name" can specify the type of cache to be acquired. The returned result for the method can be a pointer to the structure name TCACHE. "Tpcacheput / tpcacheget" can be used to cache / get data from the cache. "Tpcacheremove / tpcachemremove / tpcacheremoveall" can be used to remove an item from the cache.

According to one embodiment, the BDC layer can register a plurality of typed buffers 130 as data types that can be cached in the caching system. For example, a plurality of typed buffers may include a string (a series of characters), a carry (character array), a ptr (a pointer to a buffer), an FML typed buffer, and a VIEW type buffer. Other data types may also be supported for caching if they are registered in the BDC layer.

As shown in FIG. 1, each registered typed buffer contains metadata describing the typed buffer (eg, typed buffer metadata 132), as well as encoding and encryption as well as serialization and deserialization. It can be associated with one or more callback functions 131 that define multiple actions on the buffer.

According to one embodiment, the BDC layer may include a switch (data structure) that provides metadata and callback functions for each registered data type.

Listing 1 below shows exemplary switches according to one embodiment.

As shown in Listing 1, the switch describes the buffer type, subtype and size, serialization actions "presend" and "presend2", deserialization action "postrecv", and encoding / encryption action "encdec". May include metadata.

According to one embodiment, the CDC layer may include a set of common APIs (eg, caching API 127) to provide caching related APIs, as well as serialization / deserialization of data containing name / key value pairs, etc. Can define common behavior for multiple implementations of. The CDC layer can serialize / deserialize multiple types of data by supporting callback registration for serialization / deserialization implementations.

According to one embodiment, a common data structure (eg, a common typed buffer) 133 can be supported by the CDC layer to store the serialized bytes of the typed buffer to be cached. Each of the registered typed buffers or other data types registered in the BDC layer can be serialized and stored in a common data structure.

According to one embodiment, the CDC layer does not perform the actual caching operation and defines the required interfaces. These interfaces do not rely on any particular implementation of caching behavior. Based on the configuration, certain implementations of these interfaces can be dynamically loaded from the IDC layer.

According to one embodiment, the caching provider switch 143 and certain methods can be provided to the CDC layer and used to search for a particular implementation of the provider switch. The provider switch may contain multiple pointers to the caching behavior provided by the caching provider. Loading of each implementation of the provider switch can be initiated by the caching API in response to caching requests from the BDC layer (128). Listing 2 below shows an exemplary provider switch according to one embodiment.

As shown in Listing 2, the provider switch may include pointers that indicate caching actions such as "put", "get", and "remove". The method "TMDDCGetCachingProviderSW" is a specific method used to search for a specific implementation of a caching interface, as defined by the configuration file.

With reference to FIG. 1 again, the IDC layer can provide the actual caching behavior and may include a client and a server for each caching provider. As mentioned above, each client may be an implementation of a provider switch and can be provided for use by the CDC layer. Clients can be provided by one or more dynamic libraries, so that each of the clients can be dynamically loaded into the CDC layer. The server can use a third party application as the actual caching server or provider. Each caching provider can have its own IDC implementation, which allows the user to modify the IDC implementation in a configuration that does not change the application code.

According to one embodiment, the DTV layer may include multiple third party caching providers (eg, Coherence and CloudStore).

According to one embodiment, the BDC and CDC layers can be present in both the client application for the transaction processing environment and the servers there (eg, Tuxedo client and Tuxedo server), while the IDC and DTV layers are on the server. Can only exist in.

According to one embodiment, the configuration file can be a file in a simple line-oriented format. Properties in the configuration file can be processed in terms of lines, so the newly introduced properties do not affect the file loading process. Table 2 shows a sample list of properties in the configuration file.

According to one embodiment, a layered caching system may separate the user from the underlying caching provider and allow the user to use the same set of interfaces to perform caching operations on the system. It can be possible.

As a specific example, when a BDC layer receives a caching request from a caching client to cache a typed buffer, the BDC layer can forward the caching request to the CDC layer (123), thereby typing. The corresponding callback function in the BDC layer can be called (137) to serialize the attached buffer, and the serialized bytes can be stored in a common data structure (138). The CDC layer can access the caching operation from a particular caching provider specified by the configuration file and perform the caching operation using a common set of interfaces.

FIG. 2 further shows a system for providing distributed caching used in a transaction processing environment according to one embodiment.

As shown in FIG. 2, the caching API at the CDC layer may further include multiple objects that define a common caching interface and other common behaviors such as serialization and deserialization. Unlike external APIs that are exposed to the user, as mentioned above, caching APIs are provided for use by the caching system.

According to one embodiment, the caching API may include a cache object 223 that may represent a cache acquired by a user of the external API. This cache can provide all cache-related actions and can receive caching actions from an external API. The cache can be identified, for example, by the cache name specified by the "tdc.cache" property of the configuration file.

As shown in FIG. 2, the cache object can be associated with the cache key object 225 and the cache value object 227. A cache key object can include a method for generating and retrieving a key for a cache, and a cache value object can include a serialization interface.

According to one embodiment, the caching provider 229 can define a set of caching behaviors identified by the provider name in the configuration file, as specified by the property cache.provider. The global cache provider container 230 maintained in the process level context (TUXP) can implicitly maintain all caching providers. The cache manager 224 can be used to manage the cache in a transaction processing environment. A cache manager can be implicitly created when the user should create the cache directly, but can be associated with a single caching provider. When the cache manager is created, if the caching provider does not exist, the associated caching provider can be created internally. The global cache manager container 228 can be maintained in a thread-level context (TUXT) to manage managers implicitly created within a thread.

FIG. 3 shows a detailed class diagram of the caching API according to one embodiment.
FIG. 4 shows a method for providing distributed caching used in a transaction processing environment according to one embodiment.

As shown in FIG. 4, in step 411, the distributed caching system can be provided in a transaction processing environment. A distributed caching system is a BDC layer for receiving caching requirements from caching clients, a CDC layer for providing a common set of caching interfaces, and an IDC layer for providing an implementation of a common set of caching interfaces. And a DTV layer for providing an actual caching provider.

At step 413, the BDC layer of the distributed caching system can receive caching requests from caching clients. The caching request can be initiated using the API exposed by the BDC layer.

At step 415, the BDC layer can transfer the caching request to the CDC layer. The typed buffer associated with the caching request can be transformed into a common data structure using the callback function defined in the BDC layer.

At step 417, the CDC layer can load a particular implementation of a common set of caching interfaces from the implementation layer and perform caching operations with that particular implementation.

Serialization Support As mentioned above, the CDC layer can define a registration function for the callback function to call the serialization / deserialization operation on the typed buffer.

According to one embodiment, the typed buffer or another data type needs to be registered with the serialization handler / deserialization handler using the registration function. An example of a registration function could be:

In the above-mentioned registration function, the serialization callback function (cb1) and the deserialization function (cb2) are registered. These callback functions can be defined in the BDC layer as described above and can be illustrated in Listing 3 below.

As shown in Listing 3, a registered typed buffer or another user-defined type data type can be converted to a serialized stream and stored in the cache. The serialized stream can then be retrieved from the cache and then converted back into a user-defined data buffer.

To support a variety of data types, including typed buffers used in distributed caching systems, it is possible to provide a common data structure for storing serialized streams of these data types.

According to one embodiment, systems and methods for supporting data serialization used by distributed caching systems are described herein. A data serialization system may include a common data structure that can be used to store serialized streams / bytes of multiple data types. The data structure may include a header that contains information that describes the cache setter's architecture. When cached data is retrieved for use on a different architecture, the architecture information in the header can be used to transform the data for use on this different architecture. If the cached data is retrieved on the same architecture, the cached data can be used unconverted. The data structure may additionally include a body with variable length to allow efficient use of memory, version information about backward compatibility, and fields for optional features for expansion.

FIG. 5 shows an exemplary typed buffer according to one embodiment.
As shown in FIG. 5, the typed buffer (eg, Tuxedo type buffer) 511 is a flexible message header (FML) 513,
And user typed container module (TCM) 51
7 may be included. The TCM may further include a typed container header (TCH) 519 and a typed container body (TCB) 521. The TCB may include T_BUFFER523 and user data 529. T_BUFFER can be used to store type 525 and subtype 527 typed buffers. A typed buffer may have several non-user TCMs that can be stored in other buffers.

FIG. 6 shows a system for supporting data serialization used by a distributed caching system according to one embodiment.

As shown in FIG. 6, the data structure may be a common typed buffer 133 supported by the CDC layer. The data structure may include header 611 and body 613. The header must be aligned with 4 bytes and multiple fields, such as magic field 615, major version field 617, minor version field 618, length field 619, vdata field 622, exlen field 623, type field 625. , And the flag field 621 may be included.

According to one embodiment, the body has a length field 629 to indicate the size of the body, a T_Buffer field 626 used to store the source typed buffer types 631 and subtype 633, and a user data field. 635 and may be included.

According to one embodiment, the "magic" field can be the char used to distinguish the header, and the length field can indicate the size of the header. The flag field can indicate the state in the major version of the field or control optional features. Major version fields can indicate structural changes in the data structure. For example, a new field / member is added or removed, or the meaning of a field is changed. Minor version fields can be used to indicate changes within the major version. For example, a new bit flag is populated in the flag field.

According to one embodiment, the exlen field may describe any extra header data (eg, optional features) that would generally not be included in the header. "Exlen
If "" is not zero, the first "exlen" * 4 bytes starting with the placeholder "vdata" can be part of the header data. The extra header data can have various fields. Each field can start with a 4-byte aligned address, use first short as the unsigned short to indicate its type, and use second short as the unsigned short to indicate the length (bytes) of the field's data. , Can be serialized.

According to one embodiment, the vdata field can be a placeholder to indicate variable data, including extra header data and body. The first 4 bytes of the header are not subject to modification for other uses, and the members in the header can use big endian (vdata is not included). The size of the header does not contain variable data and therefore does not affect the length field.

According to one embodiment, the major version, length and flag fields can be used to support protocol compatibility between major versions. In addition, the flag field can indicate the state of the data, which can be one of unencoded data, encoded data and self-descriptive data.

According to one embodiment, if the data is unencoded, no action is taken during serialization and the body can be the same as the original user TCM in the typed buffer. A cache getter (for example, an application that retrieves cached data) that resides on a machine with the same architecture (for example, the same character encoding or the same endian) as the cache setter (for example, an application that stores data in the cache) is cached. Data can be searched and used.

According to one embodiment, when the data is coded, the original user TCM in the typed buffer is serialized using a particular coding mechanism, so the appropriate corresponding mechanism for the cache getter to deserialize the data. Will allow cache getters on any platform to retrieve data accurately.

According to one embodiment, the data structures described herein can provide a "self-describing" mode or state, which causes the body of the data structure to be, for example, "coded" in a typed buffer. It is possible to make it the same state as the original user TCM in the state of "not being converted". In addition, additional information about the cache setter's original architecture can be included in the header of the data structure. When cache getters located in different architectures obtain cached data, additional information can be used to transform the data for use in different architectures. If the cache getter is located on the same architecture as the cache setter, the data can be used directly without conversion.

According to one embodiment, the data structure can still support the "encoded" mode, which allows the data to be shared with other products that support the Tuxedo coding algorithm. As an example of the scenario, a Tuxedo application functions as a cache setter, and a WebLogic application using the JATMI package functions as a cache getter.

According to one embodiment, the architecture can be heterogeneous by one or more of the following: That is, 1) different endian (byte order, little endian or big endian); 2) different character sets (ASCII, EBCDIC, etc.); and 3) types with different sizes (eg, 4 or 8 bytes in length). possible).

According to one embodiment, when the "self-describing" state is used, information about structural differences can be specified in the header of the data structure. In a heterogeneous environment, the "self-describing" mode has two advantages over the coding mode. That is, 1) for the cache setter, the same performance as for the "unencoded"; and 2
) If the getter is located on the same architecture as the cache getter, it has the same performance as if it were "unencoded" for the cache getter.

As a specific example, cache setters can use data structures to store serialized bytes in their own format (eg, big endian or little endian), and in which "endian" the data is. Can store additional information that specifies. When the cache getter retrieves the data, it can use additional information to convert the data to a local format.

According to one embodiment, in a heterogeneous environment, the library can be provided to each machine, so that the receiving machine will use the library to receive cached data regardless of the architecture of the cache setter's machine. Can be converted.

As such, the data structure can improve the performance of the caching system and can store serialized bytes of various data types, including Tuxedo typed buffers.

According to one embodiment, two steps can be performed to serialize the user TCM in the typed buffer. The first step is to display and the second step is to code. As mentioned above, the functions for serialization and deserialization are realized in the callback function in the BDC layer.

According to one embodiment, the user TCM in the typed buffer can be serialized, but only the user data in the typed buffer and the T-buffer need to be cached to reduce unnecessary data, and the typed buffer. The rest of does not need to be cached.

Listing 4 shows an exemplary header of a typed buffer according to one embodiment.

FIG. 7 shows a method for supporting data serialization used by a distributed caching system according to one embodiment.

As shown in FIG. 7, in step 711, a distributed caching system may be provided in a transaction processing environment.

In step 713, a data structure used to store serialized streams / bytes of multiple data types may be provided. The data structure contains a header that contains information about the system architecture that runs the cache setup application.

In step 715, a cache-acquiring application running on a different system architecture looks up the cached data and uses information about the source system architecture to transform the data for use on different architectures.

Integration with Coherence According to one embodiment, a caching provider (eg, Coherence or CloudStore) can be used as a caching provider by configuration.

According to one embodiment, systems and methods for integrating a distributed in-memory data grid (eg, Coherence) into a distributed caching system as a caching provider are described herein. A proxy server in a distributed caching system can act as a client for a distributed in-memory data grid and can receive caching requests forwarded from IDC clients. At startup, the proxy server can load the configuration file that defines the caching system cache and the map that it caches in the distributed in-memory data grid cache, using the name of the caching system cache. You can advertise the service. Upon receiving a caching request from a caching client that specifies the requested service, the proxy server can determine the corresponding cache in the distributed in-memory data grid for access based on the requested service. ..

According to one embodiment, the data to be cached can be serialized and then transferred to a proxy server, which can store the serialized data in the corresponding in-memory data grid cache. .. When the cached data is retrieved from the corresponding in-memory data grid cache as serialized bytes and sent back to the caching client, the caching client can deserialize the data back to the original data.

FIG. 8 shows a system for integrating a distributed in-memory data grid into a distributed caching system as a caching provider according to one embodiment.

As shown in FIG. 8, a plurality of computer nodes (eg, node A805 and node B807) can be configured to function in a cluster or domain in a transaction processing environment (eg, Tuxedo server environment). Each computer node may include an application server (eg, application server A811 and application server B813).

As further shown in FIG. 8, a distributed in-memory data grid cluster (eg, Coherence) 831 may be supported on multiple computer nodes. A distributed in-memory data grid can contain multiple members distributed across multiple computer nodes. For example, Coherence member A819 and Coherence member C823 can reside on computer node A, while Coherence member B821 and Coherence member D825 can reside on computer node B.

According to one embodiment, one or more proxy servers can be provided on each computer node for load balancing and performance improvement. For example, proxy servers 815 and 817 for Coherence are provided on computer node A and computer node B, respectively.

According to one embodiment, each proxy server can be implemented by a Tuxedo Java® server and can function as a server in a distributed caching system. Caching requests from caching clients (eg, Tuxedo clients or servers) can be forwarded to their respective proxy servers by invoking transaction procedures. Each proxy can then forward one or more caching requests to a distributed in-memory data grid to receive the corresponding response.

According to one embodiment, each proxy server can act directly as a Java® client for a distributed in-memory data grid. The configuration file can specify how to access the distributed in-memory data grid, for example, whether to access one or more distributed or replicated caches. it can. If read access is high and write access is low, a replicated cache can be configured for access.

FIG. 9 further shows a system for integrating a distributed in-memory data grid into a distributed caching system as a caching provider according to one embodiment.

As shown in FIG. 9, the proxy server 930 may be present at the CDC layer to receive the transaction procedure call 929 from the caching provider switch implementation 943 for Coherence. Transaction procedure calls can be generated by the server hosting the caching provider switch implementation after receiving a caching request from the caching client to the distributed caching system. The transaction procedure call may include (928) serialized bytes from a common typed buffer.

According to one embodiment, the caching provider implementation for Coherence can be an IDC client provided from the IDC layer to the CDC layer. Coherence 932 can be configured to be the default caching provider. Thus, the provider switch implementation and the method used to load the provider switch implementation can be integrated into the Tuxedo dynamic libraries libtux and libws. In this case, the former can be used by the Tuxedo server and its own client, while the latter can be used for the Tuxedo / WS client.

According to one embodiment, a Coherence-based provider switch implementation or IDC client can forward a caching request to a proxy server via tpcall. Various buffer types can be used based on the type of request to reduce unnecessary copies. Table 3 shows a sample list of typed buffers that can be used based on the type of caching request.

According to one embodiment, the proxy server can load configuration properties from the configuration file when it is started. In this case, the provided Tuxedo cache for which configuration properties can be defined can be a configured logical or physical cache in a distributed caching system. The proxy server can advertise the service using the Tuxedo cache name. An example of a list of properties from the configuration file can be shown in Listing 5 below.

According to one embodiment, the proxy server can advertise a Tuxedo service named "tc" with the above properties. The IDC client can forward the request for the cache "tc" to the service "tc" advertised by the proxy server by tpcall. As shown in Listing 3, the property can specify a mapped Coherence cache for the cache configured in the distributed caching system. If the caching client needs to get the cache with the command "getcache", the proxy server can send back to the caching client all the properties needed for this cache (for example, the property options.encoding).

According to one embodiment, the name of the requested service is Coherence by the configuration file.
The proxy server can determine the Coherence cache name based on the requested service if it can be the same as the name of the Tuxedo cache mapped to the cache.

According to one embodiment, the proxy server can act as a client of Coherence. The proxy server can be a unique client (a member of a Coherence cluster) or a remote client, as defined by the Coherence configuration file used by the proxy server.

According to one embodiment, the Coherence cache can be a distributed cache, a local cache or any other type of cache, as determined by the requirements of the application.

According to one embodiment, for example, "put" to store data in the cache.
When the command ")" is called in the application, the data can be serialized and then transferred to the proxy server. When the proxy server receives serialized data that can be of the type byte [], the proxy server can store the serialized data in Coherence.

Similarly, when a command such as "get" is called in an application to retrieve data from the cache, the cached data is retrieved from the Coherence of type []. It is then sent back to the caching client, which can deserialize the data into its original format.

FIG. 10 shows a method for integrating a distributed in-memory data grid into a distributed caching system as a caching provider according to one embodiment.

As shown in FIG. 10, in step 1011 the proxy server can be provided to the distributed caching system in a transaction processing environment. The proxy server can load the configuration file that defines the caching system cache and the map that it caches in the distributed in-memory data grid cache and advertise the service using the name of the caching system cache. ..

In step 1013, the proxy server can receive the caching request. The caching request is forwarded when the transaction procedure is called from the IDC client of the distributed caching system.

At step 1015, the proxy server can determine the corresponding cache in the distributed in-memory data grid to access based on the requested service when invoking the transaction procedure.

Service Caching The decentralized caching system described above can provide the following caching features: That is, caching that has very few accesses and updates, can cache the Tuxedo buffer identified by the key, and provides tunable quality services including replication access, non-replication access, local access and remote access. Features can be provided.

According to one embodiment, a system and method for caching the results returned from a service using a distributed caching system in a transaction processing environment is described herein. The configuration file contains a caching section that contains an entry that describes which cache should be used to cache the results returned by the service and how to generate the key used to identify the cached results. Can include. When a request for a service is received from a client, the application server core in the transaction processing environment determines if the associated cached data is in the cache identified by the key generated using the configuration file. can do. If present, the application server core can return the cached data directly instead of calling the service. In other cases, the application server core can call the service and use the generated key to cache the data in the cache specified by the configuration file and return the result to the client.

According to one embodiment, the result returned for the service to be cached can be a search result from the database based on the input keywords in the service request.

If a service (eg, a Tuxedo service) can spend a relatively long time returning the same result in response to a particular request over a period of time, the service caching feature can significantly improve system performance. .. In addition, this caching feature allows the user to cache the results returned by the service without modifying existing code.

According to one embodiment, the configuration file can specify how to generate a key that should be used to identify the cached result. The key for such identification is a simple solid string, a string consisting of a service name, a string consisting of request data, and a string consisting of a service name and request data. Can be one of.

According to one embodiment, if the request data should be used to generate the key, the entire request data or part of the data can be used as part of the key according to the typed buffer containing the request data. The user can use:

1) Part of the STRIGN / CARRAY buffer identified by the start / end indicator;
2) One or several fields in the VIEW / VIEW32 buffer;
3) One or several fields in the FML / FML32 buffer; or
4) One or several fields in the XML buffer.

According to one embodiment, in a transaction processing environment, a typed buffer, such as an FML type buffer, may contain multiple sets of name-value pairs. A typed buffer can be used to send a request from the client to the server and return the result from the server to the client. Cached service results can contain multiple sets of name-value pairs that can contain external data for a particular caching request. For example, some of the cached name-value pairs may not be needed for a particular request, but these name-value pairs may be needed for subsequent caching requests. ..

Therefore, according to one embodiment, by using the key generated from the request data, the client application can accurately indicate the necessary data and search only those data, thereby reducing the access time. It can be reduced and the performance can be enhanced.

FIG. 11 shows a system for caching the results returned from a service using a distributed caching system in a transaction processing environment according to one embodiment.

As shown in FIG. 11, a distributed caching system can be configured to use Coherence as a caching provider 1119 which may include multiple distributed or replicated caches (eg, cache A1121 and cache B1123). ..

As further illustrated, the configuration file 1104 for a transaction processing environment may include a service caching section 1107 that may include an entry describing how to use the distributed caching system.

For example, the caching section describes which cache should be used to cache what is returned from a particular service, as illustrated by cache A1110 for service A and cache B1111 for service B. be able to.

According to one embodiment, additional entries in the section include method 1113 for generating a key for service A, and method 1 for generating a key for service B.
As indicated by 115, it is possible to describe how to generate a key that should be used to identify cached results from a particular service. As mentioned above, the key generation method can define which field of the data in the request should be used when generating the key, based on the type of buffer containing the request data.

With reference to FIG. 11, the application server core (eg, Tuxedo core) 1114 can be provided to pass the returned results from service 1102 to the client application (eg, Tuxedo client) 1101. The application server core can be associated with an application server A (eg, Tuxedo server) 1117 capable of executing multiple services (eg, service A1105 and service B1109). The application server core can also be associated with service caching logic 1128, which is used in determining whether to call a particular service for a result or use a cached result.

As a specific example, when a request for service A1125 is received by the application server, the application server core associated with it checks the cache configured for service A and follows the relevant entry for the service in the configuration file. It is possible to determine if relevant cached data exists in the cache, as identified by the generated key 1127. If present, the application server can return the cached data directly instead of calling service A. If it does not exist, the application server core can call service A (1108) and return the result to the client application. Before transferring the results back to the client application, the application server core can cache the data with the generated key in a cache configured to be used by service A.

FIG. 12 shows a method for caching the results returned from a service using a distributed caching system in a transaction processing environment according to one embodiment.

As shown in FIG. 12, in step 1211 the distributed caching system identifies which cache should be used to cache the returned results for a particular service and in identifying the cached results. It can be provided in a transaction processing environment that may contain a configuration file with an entry describing how the key used should be generated.

In step 1213, the application server core associated with the application server can detect that a request for the service is being sent from the client application to the application server hosting the service and the associated cache. It is possible to determine whether the generated data exists in the cache identified by the key generated using the configuration file.

In Tep 1215, if the associated cached data exists in the cache, the application server core can return the cached data directly instead of calling the service. In other cases, the application server core can call the service, cache the data with the generated key in the cache specified by the configuration file, and return the result to the client.

The present invention comprises one or more conventional general purpose or specialized digital computers, computing devices, machines, including one or more processors, memories and / or computer readable storage media programmed according to the teachings of this disclosure. Alternatively, it may be conveniently realized using a microprocessor. Appropriate software coding can be easily prepared by a skilled programmer based on the teachings of this disclosure, as will be apparent to those skilled in the art of software technology.

In some embodiments, the invention is a non-temporary storage medium or computer (s) that contains instructions that can be used to program a computer to perform any of the processes of the invention. Includes computer program products that are readable media. This storage medium includes any type of disk, ROM, RAM, EPROM, EEPROM, DRAM, VRAM, flash memory, including floppy (registered trademark) disks, optical disks, DVDs, CD-ROMs, microdrives, and magneto-optical disks. It may include, but is not limited to, devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of medium or device suitable for storing instructions and / or data.

Previous descriptions of the present invention are provided for purposes of illustration and description. It is not intended to be exhaustive or limited to the disclosed form itself. Numerous changes and variations will be apparent to those skilled in the art. The embodiments are intended to allow others skilled in the art to understand the various embodiments and the various variations suitable for the particular application intended by best explaining the principles of the invention and their practical applications. Selected and explained in. The scope of the present invention is intended to be defined by the appended claims and their equivalents.

Claims (8)

A system for integrating a distributed in-memory data grid into a distributed caching system in a transaction processing environment.
With a computer that contains one or more microprocessors,
A transaction processing environment including a plurality of layers running on the computer and providing caching functions, the plurality of layers including a common distributed caching (CDC) layer and an implementation layer, said system. Furthermore,
A distributed in-memory data grid that operates in the implementation layer,
Including a proxy server in the CDC layer, the proxy server acts as a client to the distributed in-memory data grid, receives a caching request when invoking a transaction procedure from the CDC layer, and is associated with caching. The data is stored in the cache in the distributed in-memory data grid or searched from the cache.
A system in which the proxy server loads properties from a configuration file, the loaded properties define a cache, and the defined cache is mapped to a cache in the distributed in-memory data grid . The system of claim 1, wherein the distributed in-memory data grid is Coherence. The system according to claim 1 or 2 , wherein the proxy server advertises a service using the name of the defined cache. The proxy server is used to perform caching operations based on the defined cache and based on the mapping between the defined cache and the cache in the distributed in-memory data grid. The system according to any one of claims 1 to 3, which determines the cache in the distributed in-memory data grid. The invention according to any one of claims 1 to 4 , wherein one or more additional proxy servers are provided on each computer node hosting the distributed in-memory data grid for load balancing. system. The system according to any one of claims 1 to 5 , wherein the proxy server is a Java (registered trademark) server. A method for integrating a distributed in-memory data grid into a distributed caching system in a transaction processing environment.
The plurality of layers include a common distributed caching (CDC) layer, which includes a step of providing a transaction processing environment including a plurality of layers that are executed on a computer including one or more microprocessors and that provide caching functions. And the implementation layer, the method further comprises.
Steps to provide a distributed in-memory data grid that operates in the implementation layer,
Including the step of providing a proxy server in the CDC layer, the proxy server functions as a client for the distributed in-memory data grid, receives a caching request when calling a transaction procedure from the CDC layer, and receives the caching. the data associated with the request, retrieves or from the cache is stored in the cache in the distributed-memory data grid,
A method in which the proxy server loads properties from a configuration file, the loaded properties define a cache, and the defined cache is mapped to a cache in the distributed in-memory data grid . A program that stores a set of instructions for integrating a distributed in-memory data grid into a distributed caching system in a transaction processing environment, said 1 when executed by one or more processors. Have one or more processors perform the following steps, the following steps
It includes a step of providing a transaction processing environment that is executed on a computer and includes a plurality of layers that provide caching functions, the plurality of layers including a common distributed caching (CDC) layer and an implementation layer. The following steps further
Steps to provide a distributed in-memory data grid that operates in the implementation layer,
Including the step of providing a proxy server in the CDC layer, the proxy server functions as a client for the distributed in-memory data grid, receives a caching request when calling a transaction procedure from the CDC layer, and receives the caching. the data associated with the request, retrieves or from the cache is stored in the cache in the distributed-memory data grid,
A program in which the proxy server loads properties from a configuration file, the loaded properties define a cache, and the defined cache is mapped to a cache in the distributed in-memory data grid .

Images