JP2020017288A - System and method for providing distributed caching in transactional processing environment - Google Patents

Abstract

To provide a system and method for providing distributed caching in a transactional processing environment.SOLUTION: A caching system disclosed herein includes a plurality of layers that provide a feature for a plurality of data types, and is configured for use with a plurality of caching providers. A common data structure stores serialized bytes of each data type and architecture information of a source platform executing a cache-setting application, and a cache-getting application can convert the serialized bytes to a local format. A proxy server acts as a client to a distributed in-memory grid, and advertises services to a caching client. Each of the advertised services matches a cache in the distributed in-memory data grid.SELECTED DRAWING: Figure 1

Description

Field of the Invention:
Embodiments of the present invention relate generally to application servers and cloud environments, and more particularly, to systems and methods for providing distributed caching in a transaction processing environment.

background:
In a transaction processing environment such as a Tuxedo (registered trademark) server environment, a distributed caching system that caches user-related data or application data to improve performance may be difficult. Because multiple data types can be used to send data between client and server processes, different customers may choose different caching solutions. These are areas that 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 an application programming interface (API) by caching the client to interact with the caching system, including multiple buffer types and each buffer type. One or more callback functions can be registered. The common caching layer can support a common data structure, and when a caching request is received from the top layer, the callback function there is used to use the specific buffer type associated with the caching request and the common data. Conversions can be made to and from the structure. The common caching layer can define a set of common APIs to provide caching-related APIs and common behavior for multiple implementations such as key and value data serialization / deserialization. Can be defined. The provider switch and associated API can be used to load a particular implementation of the provider switch from the implementation layer. The provider switch may include a pointer to a caching operation provided by a particular caching provider. The configuration file can be used to specify 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 a distributed caching system are described herein. Data serialization systems may include common data structures. A common data structure can be used to store serialized streams / bytes of multiple data types. The data structure may include a header containing information describing the architecture of the cache setter. 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 fields for variable length bodies to allow efficient use of memory, version information for backward compatibility, and optional features for extensions.

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

  According to one embodiment, systems and methods are described herein for caching results returned from a service using a distributed caching system in a transaction processing environment. The configuration file contains a caching section containing entries that describe which cache to use to cache the results returned from the service and how to generate the keys used to identify the cached results. May be included. When a request for a service is received from a client, the application server core of the transaction processing environment determines whether the associated cached data is present in the cache identified by the key generated using the configuration file. can do. If so, the application server core can return the cached data directly instead of invoking the service. In other cases, the application server core may invoke the service, use the generated key to cache data in the cache specified by the configuration file, and return the result to the client.

FIG. 2 illustrates a system for providing distributed caching in a transaction processing environment, according to one embodiment. FIG. 3 further illustrates a system for providing distributed caching used in a transaction processing environment, according to one embodiment. FIG. 4 is a detailed class diagram illustrating a caching API, according to one embodiment. FIG. 4 illustrates a method for providing distributed caching used in a transaction processing environment, according to one embodiment. FIG. 4 illustrates an exemplary typed buffer according to one embodiment. FIG. 2 illustrates a system for supporting data serialization used by a distributed caching system, according to one embodiment. FIG. 4 illustrates a method for supporting data serialization used by a distributed caching system, according to one embodiment. FIG. 2 illustrates a system for integrating a distributed in-memory data grid with a distributed caching system as a caching provider, according to one embodiment. FIG. 2 further illustrates a system for integrating a distributed in-memory data grid with a distributed caching system as a caching provider, according to one embodiment. FIG. 4 illustrates a method for integrating a distributed in-memory data grid with a distributed caching system as a caching provider, according to one embodiment. FIG. 4 illustrates a system for caching results returned from a service using a distributed caching system in a transaction processing environment, according to one embodiment. FIG. 4 illustrates a method for caching results returned from a service using a distributed caching system in a transaction processing environment, according to one embodiment.

Detailed description:
In a transaction processing environment (eg, a Tuxedo server environment), buffers need to be allocated before a message can be sent from one process to another. Complex applications in such an environment can be installed in heterogeneous systems that communicate over multiple networks using various protocols. As a result, different types of buffers are required, and each buffer type requires various routines to initialize, send, receive, and encode and decode data.

  Typically, when a user (e.g., an application developer) caches a typed buffer in a distributed caching system for improved performance, the user must write customized code for the particular typed buffer. There is. Furthermore, if a different caching provider is used after the development of the application is completed, the code needs to be additionally changed to accommodate the change in the caching provider.

Distributed Caching System 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 an application programming interface (API) by caching the client to interact with the caching system, with multiple buffer types and one or more for each buffer type. You can register a callback function. The common caching layer can support a common data structure, and upon receiving a caching request from the top layer, uses a callback function there to share the common data type with the specific buffer type associated with the caching request. Conversions can be made to and from the structure. The common caching layer defines a set of common APIs to provide caching-related APIs and defines common behavior for multiple implementations, such as key / value data serialization / deserialization. Can be. The provider switch and associated API can be used to load a particular implementation of the provider switch from the implementation layer. The provider switch may include a pointer to a caching operation provided by a particular caching provider. The configuration file can be used to specify data coding and which caching provider to use for the caching system.

  A tiered caching system can separate users from underlying caching providers, thereby making the system easier to use and easier to extend.

For example, a caching system can be used with multiple caching providers and can cache multiple data types without having to change the user's application. Regardless of what buffer types the developer needs to cache, and regardless of which caching providers are to be configured for that caching system, users use the same set of APIs. To perform a caching operation.

  According to one embodiment, a distributed caching system can reduce the number of accesses and updates, cache multiple types of buffers, each identified by a key, replicated access, non-replicated access, Local and remote access can be provided.

  FIG. 1 illustrates a system for providing distributed caching used in a transaction processing environment, according to one embodiment.

  As shown in FIG. 1, the distributed caching system 105 includes a caching client (eg, a Tuxedo client or server) 101 for storing (106) data in or retrieving (107) data from the cache. In a transaction processing system (e.g., Tuxedo server environment) 100 that is used by Microsoft.

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

  According to one embodiment, the BCD layer is the top layer for the caching client and can handle multiple typed buffers, and after converting the typed buffers 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 caching clients to communicate with the caching system. For example, an external API can be used directly in an application to cache data or retrieve data from the cache.

  Table 1 below shows a list of exemplary interfaces of the external API according to one embodiment.

  As shown in Table 1, according to one embodiment, the external API obtains a handle to the cache, puts a buffer in the cache, associates the buffer with a key, and removes and retrieves the buffer from the cache. It may include the method to be used.

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

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

  As shown in FIG. 1, each registered typed buffer includes metadata describing the typed buffer (eg, typed buffer metadata 132), encoding and encryption, and serialization and deserialization. One or more callback functions 131 that define a plurality of actions on the buffer.

  According to one embodiment, the BDC layer may include switches (data structures) that provide metadata and callback functions for each registered data type.

  Listing 1 below shows an exemplary switch according to one embodiment.

As shown in Listing 1, the switch describes the buffer type, subtype and size, the serialization operations "presend" and "presend2", the deserialization operation "postrecv", and the encoding / encryption operation "encdec". Can 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, and serialization / deserialization of data including name / key-value pairs, etc. May 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 may 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 with the BDC layer may be serialized and stored in a common data structure.

  According to one embodiment, the CDC layer does not perform the actual caching operation, but defines the required interface. These interfaces do not rely on a specific implementation of the caching operation. Based on the configuration, specific implementations of these interfaces can be dynamically loaded from the IDC layer.

According to one embodiment, the caching provider switch 143 and a particular method may be provided to the CDC layer and used to search for a particular implementation of the provider switch. The provider switch may include a plurality of pointers to caching operations provided by the caching provider. Loading of each implementation of the provider switch may be initiated by the caching API in response to a caching request 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 to caching operations 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 a configuration file.

  Referring again to FIG. 1, the IDC layer can provide the actual caching behavior and can include clients and servers for each caching provider. As described above, each client may be an implementation of a provider switch and may 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 an actual caching server or provider. Each caching provider can have its own IDC implementation, which allows the user to change the IDC implementation with a configuration without application code changes.

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

  According to one embodiment, the BDC and CDC layers may reside in both the client application to the transaction processing environment and the servers therein (eg, Tuxedo clients and Tuxedo servers), and the IDC and DTV layers reside on the server. May only exist.

  According to one embodiment, the configuration file may be a file in a simple line-oriented format. Properties in the configuration file can be handled from a line perspective, so 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 tiered caching system may provide a separation between a user and an underlying caching provider and use the same set of interfaces for the user to perform caching operations on the system. May be possible.

  As a specific example, when the BDC layer receives a caching request from the caching client to cache the typed buffer, the BDC layer can forward the caching request to the CDC layer (123), which allows the type to be cached. A corresponding callback function in the BDC layer can be invoked (137) to serialize the attached buffer, and the serialized bytes can be stored in a common data structure (138). Using a common set of interfaces, the CDC layer can access and perform caching operations from a particular caching provider specified by a configuration file.

  FIG. 2 further illustrates a system for providing distributed caching for use in a transaction processing environment, according to one embodiment.

  As shown in FIG. 2, the caching API in the CDC layer may further include multiple objects that define common caching interfaces and other common behaviors, such as serialization and deserialization. Unlike an external API exposed to the user, as described above, a caching API is 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 obtained by a user of the external API. This cache can provide all cache-related operations and can receive caching operations from external APIs. The cache may be identified, for example, by the cache name specified by the “tdc.cache” property in the configuration file.

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

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

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

As shown in FIG. 4, at step 411, a distributed caching system can be provided in a transaction processing environment. A distributed caching system includes 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 to provide the actual caching provider.

  In step 413, the BDC layer of the distributed caching system can receive a caching request from a caching client. A caching request can be initiated using an API exposed by the BDC layer.

  In step 415, the BDC layer can forward the caching request to the CDC layer. Typed buffers associated with caching requests can be converted to a common data structure using callback functions defined at the BDC layer.

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

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

  According to one embodiment, the typed buffer or another data type needs to be registered with the serialization / deserialization handler using a registration function. Examples of the registration function may be as follows.

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

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

  To support various data types, including typed buffers used in distributed caching systems, a common data structure for storing serialized streams of these data types can be provided.

  According to one embodiment, systems and methods for supporting data serialization used by a distributed caching system 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 containing information describing the architecture of the cache setter. 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 without conversion. The data structure may additionally include fields for variable length bodies to allow efficient use of memory, version information for backward compatibility, and optional features for extensions.

FIG. 5 illustrates an exemplary typed buffer according to one embodiment.
As shown in FIG. 5, a typed buffer (eg, Tuxedo typed buffer) 511 includes 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_BUFFER 523 and user data 529. T_BUFFER can be used to store typed buffer type 525 and subtype 527. Typed buffers may have some non-user TCMs that can be stored in other buffers.

  FIG. 6 illustrates 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 a header 611 and a body 613. The header needs to be aligned with 4 bytes and has multiple fields, eg, magic field 615, major version field 617, minor version field 618, length field 619, vdata field 622, exlen field 623, type field 625. , And a flag field 621.

  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 type 631 and subtype 633, and a user data field. 635.

According to one embodiment, the "magic" field may be a char used to distinguish the header, and the length field may indicate the size of the header. The flag field may indicate status in the major version field or control optional features. The major version field can indicate a structural change in the data structure. For example, new fields / members are added or deleted, or the meaning of the fields is changed. The minor version field can be used to indicate a change in the major version. For example, a new bit flag is entered in the flag field.

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

According to one embodiment, the fields of vdata may be placeholders to indicate variable data including extra header data and body. The first four bytes of the header cannot be changed for other uses, and members in the header can use big endian (vdata is not included). The size of the header does not include variable data, and thus 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 may indicate a state of the data, which may be one of uncoded data, coded data, and self-describing data.

  According to one embodiment, if the data is not encoded, no operations are performed during serialization and the body may be the same as the original user TCM in the typed buffer. A cache getter (eg, an application that retrieves cached data) that resides on a machine with the same architecture (eg, the same character encoding or the same endian) as a cache setter (eg, an application that stores data in the cache) is cached. The retrieved data can be retrieved and used.

  According to one embodiment, as the data is encoded, the original user TCM in the typed buffer is serialized using a particular encoding mechanism, so that the cache getter has the appropriate corresponding mechanism to deserialize the data. If you use, the cache getter on any platform will be able to get the data accurately.

  According to one embodiment, the data structures described herein can provide a “self-describing” mode or state, which allows the body of the data structure to be stored in a typed buffer, for example, by In the "unconverted" state, the same state as the original user TCM can be obtained. In addition, additional information about the original architecture of the cache setter can be included in the header of the data structure. If a cache getter located in a different architecture obtains the cached data, the additional information can be used to transform the data for use in a different architecture. If the cache getter is located in 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, thereby allowing data to be shared with other products that support the Tuxedo encoding algorithm. As an example of a scenario, there can be mentioned an example in which 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 may be heterogeneous by one or more of the following: That is, 1) different endians (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, if a "self-describing" state is used, information about the 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. 1) the same performance as "unencoded" for the cache setter; and 2
3.) If the getter is located in the same architecture as the cache getter, it has the same performance for the cache getter as it does for the "unencoded" case.

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

  According to one embodiment, in a heterogeneous environment, a library can be provided to each machine, so that the receiving machine can use the library to store 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 of the typed buffer. The first step is to display and the second step is to encode. As described above, the functions for serialization and deserialization are implemented in the callback function in the BDC layer.

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

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

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

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

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

  In step 715, a cache acquisition application running on a different system architecture retrieves the cached data and uses the information about the source system architecture to transform the data for use on the different architecture.

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 are described herein for integrating a distributed in-memory data grid (eg, Coherence) into a distributed caching system as a caching provider. A proxy server in a distributed caching system can function 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 a configuration file that defines the caching system cache and maps to cache in the distributed in-memory data grid cache, using the name of the caching system cache to: The service can be advertised. Upon receiving a caching request from a caching client specifying the requested service, the proxy server may determine a corresponding cache in the distributed in-memory data grid to access based on the requested service. .

  According to one embodiment, the data to be cached can be serialized before being forwarded to a proxy server, which can store the serialized data in a 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 data.

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

  As shown in FIG. 8, multiple computer nodes (eg, Node A 805 and Node B 807) can be configured to function in a cluster or domain in a transaction processing environment (eg, a Tuxedo server environment). Each computer node may include an application server (eg, application server A 811 and application server B 813).

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 may include multiple members distributed across multiple computer nodes. For example, Coherence member A 819 and Coherence member C 823 may reside on computer node A, while Coherence member B 821 and Coherence member D 825 may reside on computer node B.

According to one embodiment, one or more proxy servers may be provided on each computer node for load balancing and performance enhancement. 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) may be forwarded to each proxy server by invoking a transaction procedure. Each proxy can then forward one or more caching requests to the distributed in-memory data grid and receive a corresponding response.

  According to one embodiment, each proxy server may function directly as a Java client to a distributed in-memory data grid. The configuration file may 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 illustrates a system for integrating a distributed in-memory data grid with a distributed caching system as a caching provider, according to one embodiment.

As shown in FIG. 9, a proxy server 930 may reside at the CDC layer to receive a call 929 to a transaction procedure from a caching provider switch implementation 943 for Coherence. The invocation of the transaction procedure 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 call to the transaction procedure may include (928) serialized bytes from a common typed buffer.

According to one embodiment, the caching provider implementation for Coherence may 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 the native client, and 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 the caching request to the 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, when started, can load configuration properties from a configuration file. In this case, the provided Tuxedo cache that the configuration properties can define can be a configured logical or physical cache in a distributed caching system. The proxy server can use the Tuxedo cache name to advertise the service. An example of a list of properties from the configuration file can be shown in Listing 5 below.

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

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

According to one embodiment, the proxy server can function as a client of Coherence. A 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 may 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, to store data in the cache, for example, "put
) "Is called in the application, the data may be serialized before being transferred to the proxy server. When the proxy server receives the serialized data, which may be of type byte [], the proxy server can store the serialized data in Coherence.

Similarly, when a command is called in an application to retrieve data from the cache, for example, a "get" command, the cached data is retrieved from the Coherence with a type of byte [], Sent back to the caching client, which can deserialize the data into its original format.

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

  As shown in FIG. 10, in step 1011 the proxy server can provide 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 to cache in the distributed in-memory data grid cache and advertise the service using the name of the caching system cache .

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

  At step 1015, the proxy server may determine a corresponding cache in the distributed in-memory data grid to access based on the requested service upon invocation of the transaction procedure.

Service Caching The distributed caching system described above can provide the following caching features. That is, caching in which the number of accesses and updates is very low, the Tuxedo buffer identified by the key can be cached, and adjustable quality services including duplicate access, non-duplicate access, local access and remote access are provided. Features can be provided.

  According to one embodiment, systems and methods are described herein for caching results returned from a service using a distributed caching system in a transaction processing environment. The configuration file contains a caching section containing entries that describe which cache to use to cache the results returned from the service and how to generate the keys used to identify the cached results. May be included. When a request for a service is received from a client, the application server core of the transaction processing environment determines whether the associated cached data is present in the cache identified by the key generated using the configuration file. can do. If so, the application server core can return the cached data directly instead of invoking the service. In other cases, the application server core may invoke the service, 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 results returned for the service to be cached may be search results from a database based on input keywords in the service request.

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

According to one embodiment, the configuration file may specify how to generate the key to be used to identify the cached result. Keys for such identification use include simple solid strings, strings composed of service names, strings composed of request data, and strings composed of service names and request data. May be one of the following.

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

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

  According to one embodiment, in a transaction processing environment, a typed buffer, such as an FML-type buffer, may include multiple sets of name-value pairs. Typed buffers can be used to send requests from the client to the server and return results from the server to the client. A cached service result may include multiple sets of name-value pairs that may include 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 a subsequent caching request .

  Thus, according to one embodiment, using a key generated from the requested data allows the client application to pinpoint the required data and retrieve only those data, thereby reducing access time. Can reduce and enhance performance.

  FIG. 11 illustrates a system for caching 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 that can include multiple distributed or replicated caches (eg, cache A 1121 and cache B 1123). .

  As further shown, the configuration file 1104 for the transaction processing environment may include a service caching section 1107, which may include entries describing how to use the distributed caching system.

  For example, the caching section describes which cache to use to cache return from a particular service, as illustrated by cache A 1110 for service A and cache B 1111 for service B. be able to.

According to one embodiment, the additional entries in the sections are a method 1113 for generating a key for service A and a method 1 for generating a key for service B.
As indicated by 115, it can describe how to generate a key to be used in identifying cached results from a particular service. As described 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 requested data.

  Referring to FIG. 11, an application server core (eg, Tuxedo core) 1114 may provide the returned results for passing from the service 1102 to a client application (eg, Tuxedo client) 1101. The application server core may be associated with an application server A (eg, Tuxedo server) 1117 that may execute multiple services (eg, service A 1105 and service B 1109). The application server core may also be associated with service caching logic 1128 that is used in deciding whether to invoke a particular service for the result or to use the cached result in the cache.

  As a specific example, when a request for service A 1125 is received by an application server, its associated application server core checks the cache configured for service A and according to the relevant entry for the service in the configuration file. A determination can be made whether relevant cache data, such as identified by the generated key 1127, is present in the cache. If so, the application server can return the cached data directly instead of calling service A. If not, the application server core may invoke service A (1108) and return the result to the client application. Before forwarding the result back to the client application, the application server core may cache the data using the generated key in a cache configured to be used by service A.

  FIG. 12 illustrates a method for caching 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 determines which cache to use 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 can include a configuration file with entries describing how the keys to be used should be generated.

  In step 1213, the application server core associated with the application server may 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 can be determined whether the data obtained is present in the cache identified by the key generated using the configuration file.

  At step 1215, if the relevant cached data is present in the cache, the application server core can return the cached data directly instead of invoking the service. In other cases, the application server core may invoke the service, cache the data using the generated key in the cache specified by the configuration file, and return the result to the client.

The present invention is directed to one or more conventional general purpose or special purpose digital computers, computing devices, machines, including one or more processors, memory and / or computer readable storage media programmed in accordance with the teachings of the present disclosure. Alternatively, it may be conveniently implemented using a microprocessor. Appropriate software coding can be readily prepared by skilled programmers based on the teachings of this disclosure, as will be apparent to those skilled in the software art.

  In some embodiments, the present invention relates to a non-transitory storage medium or computer (s) storing instructions that can be used to program a computer to perform any of the processes of the present invention. Includes a computer program product that is a readable medium. This storage medium can be any type of disk, including floppy (registered trademark) disk, optical disk, DVD, CD-ROM, microdrive, and magneto-optical disk, ROM, RAM, EPROM, EEPROM, DRAM, VRAM, flash memory It may include, but is not limited to, a device, a magnetic or optical card, a nanosystem (including a molecular memory IC), or any type of medium or device suitable for storing instructions and / or data.

  The foregoing description of the present invention has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations will be apparent to practitioners skilled in the art. The embodiments are to best explain the principles of the invention and its practical applications so that others skilled in the art can appreciate the various embodiments and the various variations that are appropriate for the particular intended application. Is selected and described. It is intended that the scope of the invention be defined by the following claims and their equivalents:

Claims (78)

A system for providing distributed caching in a transaction processing environment,
A computer including one or more microprocessors;
A transaction processing environment that is executed on the computer and includes a plurality of layers for providing a caching function, wherein the plurality of layers include:
A buffer-based distributed caching (BDC) layer for receiving caching requests;
An implementation layer comprising a plurality of implementations of the caching operation, each implementation being from a different caching provider, wherein the plurality of layers further comprises:
Includes a common distributed caching (CDC) layer that defines common caching-related interfaces,
Upon receiving a forwarded caching request from the BDC layer, the CDC layer loads an implementation of a caching operation with the particular caching provider and performs a caching operation on data associated with the caching request. system.   The system of claim 1, further comprising a dependent third-party vendor layer that includes one or more caching providers. The system of claim 1 or 2, wherein the one or more caching providers comprises Coherence and / or CloudStore.   2. The BDC layer registers a plurality of data types used in the distributed caching system, each registered data type being associated with a switch that defines an operation for that data type. The system according to any one of claims 1 to 3.   5. The system of claim 4, wherein the defined actions for each registered data type include one or more of serialization, deserialization, encoding or decoding.   The system of claim 1, wherein the CDC layer includes an application programming interface (API) for providing the common caching-related interface.   The system of any one of claims 1 to 6, wherein the CDC layer includes a caching provider switch and an associated API used in loading an implementation of a caching operation from the particular caching provider. .   The system of claim 7, wherein the caching provider switch includes a plurality of pointers, each of the plurality of pointers pointing to a caching operation provided by a particular caching provider.   9. The method of claim 1, wherein the CDC layer invokes one or more callback functions defined in the BDC layer to perform serialization or deserialization of the data associated with the caching request. The system according to paragraph. A method for providing distributed caching in a transaction processing environment, the method comprising: providing a transaction processing environment executing on one or more microprocessors and including a plurality of layers for providing caching functionality;
Receiving a caching request at a buffer-based distributed caching (BDC) layer;
At a common distributed caching (CDC) layer defining a common caching-related interface, receiving the caching request forwarded from the BDC layer;
Loading an implementation of a caching operation by a particular caching provider from the implementation layer via the CDC layer, wherein the implementation layer includes a plurality of implementations of the caching operation, Implementation is from a different caching provider, and the method further comprises:
Performing a loaded caching operation on the data associated with the caching request.   The method of claim 10, further comprising providing a dependent third party vendor layer that includes one or more caching providers. The method according to claim 10 or 11, wherein the one or more caching providers include Coherence and / or CloudStore.   The BDC layer registers a plurality of data types used in the distributed caching system, each registered data type being associated with a switch that defines an operation for that data type. The method according to any one of claims 1 to 12.   14. The method of claim 13, wherein the operations defined for each registered data type include one or more of serialization, deserialization, encoding or decoding.   15. The method of any one of claims 10 to 14, wherein the CDC layer includes an application programming interface to provide the common caching-related interface.   16. The method of any one of claims 10 to 15, wherein the CDC layer includes a caching provider switch and an associated API used in a particular implementation of the caching provider switch.   17. The method of claim 16, wherein the caching provider switch includes a plurality of pointers, each of the plurality of pointers pointing to a caching operation provided by a particular caching provider.   18. The CDC layer according to any one of claims 10 to 17, wherein the CDC layer invokes one or more callback functions defined in the BDC layer to perform serialization or deserialization of data associated with the caching request. The method described in. A non-transitory computer-readable storage medium storing a set of instructions for providing distributed caching in a transaction processing environment, the instructions when executed by one or more processors. The following steps are performed by the above processor, and the following steps are performed:
Receiving a caching request at a buffer-based distributed caching (BDC) layer;
Receiving the caching request forwarded from the BDC layer at a common distributed caching (CDC) layer, wherein the CDC layer defines a common caching-related interface, the following steps further comprising:
Loading an implementation of a caching operation by a particular caching provider from the implementation layer via the CDC layer, wherein the implementation layer includes a plurality of implementations of the caching operation, The implementation of is from a different caching provider, and the following steps further comprise:
A non-transitory computer-readable storage medium that performs a loaded caching operation on data associated with the caching request.   20. The non-transitory computer readable storage medium of claim 19, further comprising providing a dependent third party vendor layer that includes one or more caching providers. A system for supporting data serialization used in a distributed caching system in a transaction processing environment,
A computer including one or more microprocessors;
A transaction processing environment that is executed on the computer and includes a plurality of layers that provide a caching function;
A data structure including a header and a body, wherein the header includes architectural information of a source platform executing a source application that initiates the caching request, wherein data associated with the caching request is serialized, and Stored, then cached,
A system wherein when an application running on a platform with a different architecture retrieves cached data, the application uses the architecture information of the source platform to convert the cached data to a local format.   22. The system of claim 21, wherein the data structure is a typed buffer used in the transaction processing environment.   23. The system according to claim 21 or 22, wherein the architecture information of the source platform includes a character set and a byte order.   24. The method of any one of claims 21 to 23, wherein the data structure includes a version number for backward compatibility and a field for extra data for optional features to allow for future expansion. system.   25. The data structure of any one of claims 21 to 24, wherein the data structure stores serialized bytes for each of the registered data types in a BDC layer, and then stores the serialized bytes in a cache in a DTV layer. The system according to paragraph.   26. When the cached data is retrieved by an application running on a platform having the same architecture as the source architecture, the application uses the cached data directly without conversion. A system according to any one of the preceding claims. A method for supporting data serialization used in a distributed caching system in a transaction processing environment, comprising:
Providing a transaction processing environment that executes on a computer that includes one or more microprocessors and includes a plurality of layers that provide caching functionality;
Providing a data structure that includes a header and a body, wherein the header includes architectural information of a source platform executing a source application that initiates the caching request, wherein data associated with the caching request is serialized; Stored in a data structure, then stored in a cache,
A method wherein, when an application running on a platform with a different architecture retrieves cached data, the application uses the architecture information of the source platform to convert the cached data to a local format.   The method of claim 27, wherein the data structure is a typed buffer used in the transaction processing environment.   The method according to claim 27 or 28, wherein the architecture information of the source platform includes a character set and a byte order.   30. The method of any one of claims 27 to 29, wherein the data structure includes a version number for backward compatibility and a field for extra data for optional features to allow for future expansion. Method.   31. The data structure of any of claims 27 to 30, wherein the data structure stores serialized bytes for each of the registered data types in a BDC layer, and then stores the serialized bytes in a cache in a DTV layer. The method described in the section.   32. When the cached data is retrieved by an application running on a platform having the same architecture as the source architecture, the application uses the cached data directly without conversion. The method according to any one of the preceding claims. A non-transitory computer readable storage medium storing a set of instructions for supporting data serialization used in a distributed caching system in a transaction processing environment, the instructions being executed by one or more processors. And causing the one or more processors to perform the following steps, wherein:
Providing a transaction processing environment executing on the computer and including a plurality of layers for providing a caching function;
Providing a data structure that includes a header and a body, wherein the header includes architectural information of a source platform executing a source application that initiates the caching request, wherein data associated with the caching request is serialized; Stored in a data structure, then stored in a cache,
When an application running on a platform with a different architecture retrieves cached data, the application uses the architecture information of the source platform to convert the cached data to a local format. Computer readable storage medium.   33. The non-transitory computer-readable storage medium of claim 32, wherein the data structure is a typed buffer used in the transaction processing environment.   35. The non-transitory computer readable storage medium of claim 33 or claim 34, wherein the architectural information of the source platform includes a character set and a byte order.   36. The method of any one of claims 33 to 35, wherein the data structure includes a version number for backward compatibility and a field for extra data for optional features to allow for future expansion. Non-transitory computer readable storage medium.   37. The data structure of claim 33, wherein the data structure stores serialized bytes for each of the registered data types in a BDC layer, and then stores the serialized bytes in a cache in a DTV layer. A non-transitory computer-readable storage medium according to claim 1.   38. When the cached data is retrieved by an application running on a platform having the same architecture as the source architecture, the application uses the cached data directly without conversion. A non-transitory computer-readable storage medium according to any one of the preceding claims. A system for integrating a distributed in-memory data grid with a distributed caching system in a transaction processing environment,
A computer including one or more microprocessors;
A transaction processing environment running on the computer and including a plurality of layers for providing caching functionality, the plurality of layers including a common distributed caching (CDC) layer and an implementation layer, the system comprising: Is also
A distributed in-memory data grid operating at the implementation layer;
A proxy server at said CDC layer, said proxy server acting as a client to said in-memory data grid, receiving a caching request when invoking a transaction procedure from said CDC layer, and data associated with caching. For storing or retrieving from a cache in the distributed in-memory data grid. 40. The system of claim 39, wherein the distributed in-memory data grid is Coherence.   41. The proxy server loads properties from a configuration file, wherein the loaded properties define a cache and map the defined cache to a cache in the distributed in-memory data grid. System.   42. The system according to any one of claims 39 to 41, wherein the proxy server advertises a service using the name of the defined cache.   The proxy server is used in performing a caching operation based on the defined cache and based on a mapping between the defined cache and a cache in the distributed in-memory data grid. 43. The system of any one of claims 39 to 42, wherein the cache is determined in the distributed in-memory data grid. 44. The method according to any one of claims 39 to 43, 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 39 to 44, wherein the proxy server is a Java (registered trademark) server. A method for integrating a distributed in-memory data grid with a distributed caching system in a transaction processing environment, comprising:
Providing a transaction processing environment running on a computer including one or more microprocessors and including a plurality of layers that provide caching functionality, the plurality of layers comprising a common distributed caching (CDC) layer And an implementation layer, the method further comprising:
Providing a distributed in-memory data grid operating at the implementation layer;
Providing a proxy server at the CDC layer, the proxy server acting as a client to the in-memory data grid, receiving a caching request when invoking a transaction procedure from the CDC layer and associating with the caching. Storing the retrieved data in or retrieving from the cache in the distributed in-memory data grid. 47. The method of claim 46, wherein the distributed in-memory data grid is Coherence.   47. The proxy server loads properties from a configuration file, the loaded properties define a cache, and map the defined cache to the cache in the distributed in-memory data grid. 47. The method according to 47.   49. The method according to any one of claims 46 to 48, wherein the proxy server advertises a service using the name of the defined cache.   The proxy server is used in performing a caching operation based on the defined cache and based on a mapping between the defined cache and a cache in the distributed in-memory data grid. 50. The method of any one of claims 46 to 49, wherein the cache in the distributed in-memory data grid is determined.   51. The method of any one of claims 46 to 50, wherein one or more additional proxy servers are provided on each computer node hosting the distributed in-memory data grid for load balancing. Method.   52. The method according to any one of claims 46 to 51, wherein the proxy server is a Java server. A non-transitory computer-readable storage medium storing a set of instructions for integrating a distributed in-memory data grid with a distributed caching system in a transaction processing environment, the instructions comprising one or more processors. When executed, causes the one or more processors to perform the following steps, wherein:
Providing a transaction processing environment running on the computer and including a plurality of layers that provide caching functionality, the plurality of layers including a common distributed caching (CDC) layer and an implementation layer; The following steps may further include:
Providing a distributed in-memory data grid operating at the implementation layer;
Providing a proxy server at the CDC layer, the proxy server acting as a client to the in-memory data grid, receiving a caching request when invoking a transaction procedure from the CDC layer and associating with the caching. A non-transitory computer readable storage medium for storing or retrieving retrieved data in a cache in the distributed in-memory data grid. 54. The non-transitory computer-readable storage medium of claim 53, wherein the distributed in-memory data grid is Coherence.   55. The proxy server of claim 53 or 54, wherein the proxy server loads properties from a configuration file, wherein the loaded properties define a cache and map the defined cache to the cache in the distributed in-memory data grid. A non-transitory computer-readable storage medium as described.   56. The non-transitory computer readable storage medium of any one of claims 53 to 55, wherein the proxy server advertises a service using the name of the defined cache.   The proxy server is used in performing a caching operation based on the defined cache and based on a mapping between the defined cache and a cache in the distributed in-memory data grid. 57. The non-transitory computer readable storage medium of any one of claims 53 to 56, wherein the cache in the distributed in-memory data grid is determined.   58. The method of any one of claims 53 to 57, wherein one or more additional proxy servers are provided on each computer node hosting the distributed in-memory data grid for load balancing. Non-transitory computer readable storage medium. A system for caching service results in a distributed caching system in a transaction processing environment,
A computer including one or more microprocessors;
A transaction processing environment that is executed on the computer and includes a plurality of layers that provide a caching function;
A caching provider configured to be used in storing cached data;
A configuration file for the transaction processing environment, the configuration file being used in identifying which cache to use to cache the returned results for the service and the cached results. A caching section that includes an entry describing how the key to be generated should be generated.   The system of claim 59, wherein the key is generated from data associated with a caching request. Further comprising service caching logic associated with an application server core, wherein the service caching logic should retrieve the result from the cache or generate a new result based on whether the result already exists in the cache. 61. The system of claim 59 or 60, wherein the system determines whether to invoke the service to perform the call.   62. The system of any one of claims 59 to 61, wherein the application server core checks the cache to determine whether the result is in the cache.   63. The system of claim 62, wherein the application server core makes the determination based on a key generated from the requested data and a key associated with the cached data.   Each key is one of a simple contiguous string, a string composed of a service name, a string composed of the request data, and a string composed of the service name and the request data. 65. The system of claim 64.   65. The system of any one of claims 59 to 64, wherein the cache is defined for the service by the configuration file. A method for caching service results in a distributed caching system in a transaction processing environment, comprising:
Providing a transaction processing environment that executes on a computer that includes one or more microprocessors and includes a plurality of layers that provide caching functionality;
Providing a caching provider configured to be used in storing the cached data;
Providing a configuration file for the transaction processing environment, the configuration file identifying which cache to use to cache returned results for a service and identifying the cached results. A caching section that includes an entry that describes how to generate the key used for.   67. The method of claim 66, wherein the key is generated from data associated with a caching request.   Providing service caching logic associated with an application server core, wherein the service caching logic should retrieve the result from the cache based on whether the result already exists in the cache; or 68. The method of claim 66 or 67, wherein determining whether to invoke the service to generate a new result.   69. The method of any one of claims 66 to 68, wherein the application server core checks the cache to determine whether the result is in the cache.   70. The method of claim 69, wherein the application server core makes the determination based on a key generated from the requested data and a key associated with the cached data.   Each key is one of a simple contiguous string, a string composed of a service name, a string composed of the request data, and a string composed of the service name and the request data. 71. The method of claim 70. 72. The method of any one of claims 66 to 71, wherein the cache is defined for the service by the configuration file. A non-transitory computer readable storage medium storing a set of instructions for caching service results in a distributed caching system in a transaction processing environment, wherein the instructions are executed by one or more processors. , Causing the one or more processors to perform the following steps, wherein:
Providing a transaction processing environment that executes on a computer that includes one or more microprocessors and includes a plurality of layers that provide caching functionality;
Providing a caching provider configured to be used in storing the cached data;
Providing a configuration file for the transaction processing environment, the configuration file identifying which cache to use to cache returned results for a service and the cached results A non-transitory computer readable storage medium that includes a caching section that includes an entry describing how to generate a key to be used.   74. The non-transitory computer readable storage medium of claim 73, wherein the key is generated from data associated with a caching request.   Providing service caching logic associated with an application server core, wherein the service caching logic should retrieve the result from the cache based on whether the result already exists in the cache; or 75. The non-transitory computer-readable storage medium of claim 73 or 74, wherein it is determined whether to invoke the service to generate a new result.   78. The non-transitory computer readable storage medium of any of claims 73 to 75, wherein the application server core checks the cache to determine whether the result is in the cache.   77. The non-transitory computer-readable storage medium of claim 76, wherein the application server core makes the determination based on a key generated from the requested data and a key associated with the cached data.   Each key is one of a simple contiguous string, a string composed of a service name, a string composed of the request data, and a string composed of the service name and the request data. 78. The non-transitory computer readable storage medium of claim 77.