CN108733589B - Method and device for realizing distributed transaction hot deployment - Google Patents
Method and device for realizing distributed transaction hot deployment Download PDFInfo
- Publication number
- CN108733589B CN108733589B CN201810326355.8A CN201810326355A CN108733589B CN 108733589 B CN108733589 B CN 108733589B CN 201810326355 A CN201810326355 A CN 201810326355A CN 108733589 B CN108733589 B CN 108733589B
- Authority
- CN
- China
- Prior art keywords
- script
- branch transaction
- transaction component
- component
- bean
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/10—Program control for peripheral devices
- G06F13/102—Program control for peripheral devices where the programme performs an interfacing function, e.g. device driver
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/382—Information transfer, e.g. on bus using universal interface adapter
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
The present specification provides an implementation method of distributed transaction hot deployment, which is applied to an initiator, where the initiator includes at least one branch transaction component, each branch transaction component corresponds to at least one participant of the distributed transaction, and is used to invoke a service interface issued by the corresponding participant, and the method includes: acquiring a script updated by a certain branch transaction component; generating a new branch transaction component according to the updated script, and replacing the original branch transaction component; and calling a participant service interface corresponding to the branch transaction component by adopting the replaced branch transaction component.
Description
Technical Field
The present disclosure relates to the field of network communication technologies, and in particular, to a method and an apparatus for implementing distributed transaction hot deployment.
Background
A transaction refers to a series of operations (branch transactions) performed by a single logical unit of work, either performed entirely or not at all. Transaction processing can ensure that all branch transactions within the transaction range are all successful, otherwise no data is updated. The transaction can simplify the error recovery process and make the program run more stably and reliably.
When the initiator, the participant and the transaction manager of the transaction are respectively positioned on different system nodes, the transaction is a distributed transaction. A distributed transaction is initiated by an initiator, each branch transaction of the transaction is executed by a participant, and a transaction manager is responsible for all branch transactions to be either completely submitted or completely aborted.
A participant typically publishes the provided branch transaction service (i.e., the business operation performed by the participant) in the form of a service interface for invocation by the initiator that requires the branch transaction to be performed. In many application scenarios, the service interface provided by the participant needs to be modified frequently to adapt to the continuously occurring business change, and how the initiator flexibly and quickly adapts to the change of the service interface becomes a challenge for the distributed transaction implementation.
Disclosure of Invention
In view of this, the present specification provides an implementation method of distributed transaction hot deployment, applied to an initiator, where the initiator includes at least one branch transaction component, and each branch transaction component corresponds to at least one participant of the distributed transaction and is used to invoke a service interface issued by the corresponding participant, where the method includes:
acquiring a script updated by a certain branch transaction component;
generating a new branch transaction component according to the updated script, and replacing the original branch transaction component;
and calling a participant service interface corresponding to the branch transaction component by adopting the replaced branch transaction component.
The present specification also provides an apparatus for implementing distributed transaction hot deployment, which is applied to an initiator, where the initiator includes at least one branch transaction component, and each branch transaction component corresponds to at least one participant of the distributed transaction and is used to invoke a service interface issued by the corresponding participant, where the apparatus includes:
the updating script obtaining unit is used for obtaining a script after updating of a certain branch transaction component;
the component replacement unit is used for generating a new branch transaction component according to the updated script and replacing the original branch transaction component;
and the component calling unit is used for calling the participant service interface corresponding to the branch transaction component by adopting the replaced branch transaction component.
This specification provides a computer device comprising: a memory and a processor; the memory having stored thereon a computer program executable by the processor; when the computer program is run by the processor, the steps of the implementation method applied to the distributed transaction hot deployment of the initiator are executed.
The present specification provides a computer readable storage medium, on which a computer program is stored, which, when executed by a processor, performs the steps of the implementation method applied to distributed transaction hot deployment of an initiator.
It can be seen from the above technical solutions that, in the embodiments of this specification, a branch transaction component calls a service interface of a corresponding participant on an initiator, and after a script of a certain branch transaction component is updated, a new branch transaction component is generated according to the updated script to replace the original branch transaction component, so that the branch transaction component can be updated in the running process of the initiator.
Drawings
FIG. 1 is a flowchart of an implementation method applied to distributed transaction hot deployment of an initiator in an embodiment of the present specification;
FIG. 2 is a flow chart illustrating the operation of an initiator in an exemplary application of the present specification;
FIG. 3 is a hardware block diagram of an apparatus for carrying out embodiments of the present description;
fig. 4 is a logical structure diagram of an implementation apparatus applied to distributed transaction hot deployment of an initiator in the embodiment of the present specification.
Detailed Description
The embodiment of the specification provides a new implementation method of distributed transaction hot deployment, calling of an initiator to a participant service interface is implemented through a branch transaction component, and an original branch transaction component is replaced by a new branch transaction component by updating a script of the branch transaction component in the running process of the initiator, so that online upgrade of the branch transaction component is implemented.
In the embodiments of the present description, the distributed transaction employs a TCC (Try/Confirm/Cancel) mode. In the TCC mode, each participant implements a one-phase Try method, a two-phase Confirm method and a two-phase Cancel method of a branch transaction, and the methods are issued in the form of service interfaces for the initiator and the transaction manager to call.
After an initiator starts a distributed transaction, registering a participant for realizing each branch transaction of the distributed transaction with a transaction manager, and calling a phase service of the participant by adopting a service interface of each participant respectively; each participant executes a one-stage Try method of the branch transaction of the initiator, and returns an execution result of whether one stage is successful or not to the initiator; if the one-stage execution result of each participant is successful, the initiator informs the transaction manager to submit the distributed transaction, and the transaction manager calls a two-stage Confirm method of the distributed transaction participant; otherwise, the initiator informs the transaction manager to roll back the distributed transaction, and the transaction manager calls a two-stage Cancel method of the distributed transaction participant.
Embodiments of the present description apply to an initiator in a distributed transaction TCC mode. The initiator in the embodiments of the present specification may be run on any device with computing and storage capabilities, such as a mobile phone, a tablet Computer, a PC (Personal Computer), a notebook, a server, and other devices; the functions of the initiator in the embodiments of the present specification may also be implemented by a logical node operating in two or more devices.
In the embodiment of the present specification, a flow of an implementation method of distributed transaction hot deployment on an initiator is shown in fig. 1.
In the embodiment of the present specification, the calling of the service interface issued by the participant on the initiator is implemented by using a component, the component is a software unit capable of implementing a certain function, and the specific form of the component may be determined according to factors such as a software system environment and a programming language of an actual application scenario, without limitation. For example, a component may be a class, object, software package, and the like.
On the initiator, the component that conducts the distributed transaction by invoking the participant service interface is referred to as the branch transaction component. The initiator includes one to a plurality of branch transaction components, each branch transaction component corresponding to one to a plurality of participants, enabling calls to corresponding participant service interfaces. The branch transaction component needs to match the service interface of the corresponding participant in order to normally use the one-phase service provided by the participant.
The initiator loads the branch transaction components with the included scripts of the various branch transaction components at startup run time. In the running process, when the script of the branch transaction component is updated, the initiator acquires the updated component script.
The specific manner in which the initiator obtains the updated branch transaction component script may be determined according to the specific implementation of the actual application scenario, and is not limited. For example, scripts of each branch transaction component in the initiator can be saved in a predetermined storage location, the initiator can periodically inquire whether the scripts are updated or not, and if so, the updated branch transaction component scripts are read.
In one implementation, each branch transaction component script of the initiator may be registered on a DRM (Distributed Resource Manager) server, the initiator subscribes to the branch transaction component scripts from the DRM server, and when any one of the branch transaction component scripts is updated, the initiator may receive the updated script of the branch transaction component pushed by the DRM server. The DRM server may push the branch transaction component identification, and the updated script for the branch transaction component with the identification, to the originator.
And step 120, generating a new branch transaction component according to the updated script, and replacing the original branch transaction component.
The initiator may generate a new branch transaction component and replace the original branch transaction component based on the mechanisms provided in the prior art, or may implement the method by itself without limitation.
For example, in an application scenario in which an initiator regularly queries whether a script is updated, after the initiator can read a script updated by a certain branch transaction component, the updated script is compiled to obtain an updated branch transaction component, and the updated branch transaction component is dynamically loaded into an operating environment of the initiator to replace the original same branch transaction component, thereby completing the upgrading of the branch transaction component.
As another example, for an initiator implemented based on Java Spring (an open source Java development framework), each branch transaction component may be a Java Bean (a reusable component of the Java language). Spring is able to monitor and detect changes to dynamic language scripts while running an application and automatically reload the changed beans into the application context. Specifically, after the Spring container detects that a certain Bean script is updated, compiling the updated script to generate a new Bean, and assembling the new Bean into the context of the initiator to replace the original Bean with the same Bean identifier.
In one example, a script refresh validation period may be set for the initiator or for each branch transaction component, and when the script refresh validation period expires, if a branch transaction component script is updated (in the case of setting the script refresh validation period for the initiator) or a present branch transaction component script is updated (in the case of setting the script refresh validation period for each branch transaction component), a new branch transaction component generated after compiling the updated script is compiled, and the new branch transaction component is loaded to replace the original branch transaction component.
The above example can be implemented based on a combination of Groovy (a Java virtual machine based development language) and Spring. Writing a branch transaction component script into a Groovy Bean script by using a Groovy language, adding a refresh-check-delay attribute to a < lang: Groovy > element of the branch transaction component Groovy, and setting the attribute value of the refresh-check-delay as a script refresh effective period of the branch transaction component. Rewriting a script source interface of Spring, so that the rewritten script source interface can obtain a script of the Groovy Bean written in the Groovy language; the script factory postprocessor interface (interface for script replacement) of Spring is rewritten, so that the rewritten script factory postprocessor interface can support the Groovy Bean (namely, the Groovy Bean is used for script replacement).
When a script refresh effective period set by a refresh-check-delay attribute is up, if a Spring container detects that a script of a certain Groovy Bean is updated, the Spring container adopts a script source interface supporting the Groovy to obtain a Groovy Bean identifier of which the script is changed and an updated script of the Groovy Bean having the identifier; and adopting a script factor Postprocessor interface supporting the Groovy Bean to load and initialize the Groovy Bean with the identification by using the updated script.
And step 130, calling the service interface of the participant corresponding to the branch transaction component by adopting the replaced branch transaction component.
After the branch transaction component replacement is completed, in the subsequent operation process, the initiator will proceed through the updated branch transaction component when calling the service interface of the participant corresponding to the branch transaction component.
After the embodiment is applied, through the update of the branch transaction component, not only can a new service interface be adapted when the service interface of the corresponding participant changes, but also the calling parameter of the service interface of the corresponding participant can be changed, so that the execution mode of the branch transaction in the distributed transaction is changed in the running process of the initiator.
For example, when a service interface provided on a participant increases, decreases, or changes parameters passed through the service interface, a branch transaction component script matching the new service interface may be provided to the initiator, such that the branch transaction component corresponding to the participant, upon completion of the script replacement, will increase, decrease, or change parameters passed through the service interface upon invocation of the participant's service interface, enabling thermal deployment of the branch transaction component.
For another example, assume that a parameter passed by a service interface of a certain participant includes a service operation code for specifying a specific service process of a branch transaction, and different values of the service operation code correspond to different service processing processes of the branch transaction. When the branch transaction component script corresponding to the participant is updated, the service operation code can be changed from one value to another value, so that after the branch transaction component is replaced, the replaced branch transaction component can adopt the service operation code value different from that of the original branch transaction component to call the service interface of the participant, and the service processing process of the branch transaction is changed.
It can be seen that in the embodiments of the present specification, the invocation of the initiator to the participant service interface is implemented by the branch transaction component, after the script of a certain branch transaction component is updated, the original branch transaction component is replaced by the branch transaction component generated according to the updated script, so as to implement the online upgrade of the branch transaction component, when the service interface of the participant is modified, the interface adaptation can be completed by upgrading the corresponding branch transaction component by adopting the branch transaction component script matched with the new service interface, without changing the code of the initiator, so that the adaptation speed is increased, and the development workload is reduced.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
In one example application of the present specification, a distributed system employs a TCC mode for distributed transactions. The distributed system includes an initiator, a transaction manager, and a number of participants. On the initiator, the call to each participant service interface is implemented with a branch transaction component, the Groovy Bean.
The initiator is realized based on a Java Spring framework, and the scriptSource interface and the scriptFactoryPostprocessor interface of Spring are rewritten, so that the rewritten scriptSource interface can read the component script written in the Groovy language, and the rewritten scriptFactoryPostprocessor interface can replace the script of the component script written in the Groovy language, even if the scriptSource interface and the scriptFactoryPostprocessor interface support the script acquisition and replacement of the Groovy Bean. Adding a refresh-check-delay attribute to the < lang: Groovy > element of each branch transaction component Groovy Bean, and setting the attribute value of refresh-check-delay to 5 minutes (the script refresh validation period of the branch transaction component).
The script of each branch transaction component Groovy Bean is registered to the DRM server, and the initiator subscribes to each branch transaction component Groovy Bean script from the DRM server.
One operational flow of the initiator is shown in fig. 2.
In step 205, the initiator opens a local transaction for the distributed transaction and creates a proxy class in the local cache for each participant that executes the distributed transaction. After the agent classes are successfully created, a stage activity interceptor is added to each agent class and used for receiving a stage service execution result returned by a participant corresponding to the agent class.
In step 210, each agent class of the initiator performs two-phase service registration with the transaction manager for the participants of the respective agents. The transaction manager accepts the registration and records all participants of the distributed transaction.
The initiator calls the service interfaces of corresponding participants through a branch transaction component Groovy Bean assembled in the application program context of the initiator, so that the participants execute a stage service, and a stage activity interceptor corresponding to the proxy class of the participants receives a stage service execution result returned by the participants. If the one-stage execution results returned by all the participants of a distributed transaction are successful, the initiator submits the local transaction of the distributed transaction, and the transaction manager calls the two-stage submission service of all the participants of the distributed transaction after knowing that the initiator submits the local transaction; if the one-stage execution result returned by one participant is failure, the initiator rolls back the local transaction of the distributed transaction, and the transaction manager calls the two-stage roll-back service of all participants of the distributed transaction after knowing that the initiator rolls back the local transaction. The above process is a flow of executing a distributed transaction on the initiator and is not shown in fig. 2.
While the initiator executes the distributed transaction, in step 215, when the script refresh validation period of a certain branch transaction component Groovy Bean expires, the Spring container detects the update condition of the script of the branch transaction component Groovy Bean.
After an initiator subscribes to a script of the branch transaction component Groovy Bean from a DRM server, when the script of the subscribed branch transaction component Groovy Bean is updated, the DRM server pushes the identifier of the updated Groovy Bean and the updated Groovy Bean to the initiator.
And step 225, the Spring container adopts a script source interface supporting Groovy to obtain the identification of the Groovy Bean with changed script and the updated script of the Groovy Bean with the identification.
And step 230, the Spring container adopts a script factor Postprocessor interface supporting the Groovy Bean to load and initialize the Groovy Bean with the identifier by the updated script, and replaces the original Groovy Bean with the identifier.
After loading the script-updated Groovy Bean into the context of the initiator and completing the initialization of the Groovy Bean, the initiator starts to call the service interface of the corresponding participant by using the replaced Groovy Bean to perform the distributed transaction.
Corresponding to the above flow implementation, an embodiment of the present specification further provides an implementation apparatus for distributed transaction hot deployment applied to an initiator. The device can be realized by software, or by hardware or a combination of the software and the hardware. Taking a software implementation as an example, the logical means is formed by reading a corresponding computer program instruction into a memory by a Central Processing Unit (CPU) of the device in which the CPU is located. From the hardware level, besides the CPU, the memory and the storage shown in fig. 3, the device in which the implementation apparatus applied to distributed transaction hot deployment of the initiator is located generally includes other hardware such as a chip for performing wireless signal transceiving and/or other hardware such as a board for implementing a network communication function.
Fig. 4 is a device for implementing distributed transaction hot deployment, which is provided by an embodiment of the present specification and is applied to an initiator, where the initiator includes at least one branch transaction component, each branch transaction component corresponds to at least one participant of the distributed transaction and is used to invoke a service interface issued by the corresponding participant, and the device includes an update script obtaining unit, a component replacing unit, and a component invoking unit, where: the updating script obtaining unit is used for obtaining a script after updating of a certain branch transaction component; the component replacement unit is used for generating a new branch transaction component according to the updated script and replacing the original branch transaction component; the component calling unit is used for calling the participant service interface corresponding to the branch transaction component by adopting the replaced branch transaction component.
Optionally, the update script obtaining unit is specifically configured to: and receiving the updated script of the branch transaction component pushed by the distributed resource management DRM server.
Optionally, the branch transaction component is a Java Bean; the component replacement unit is specifically configured to: after detecting that a certain Bean script is updated, compiling the updated script to generate a new Bean, assembling the new Bean into the context of an initiator, and replacing the original Bean with the same Bean identification.
In one example, the component replacement unit is specifically configured to: when the script refreshing effective period comes to an end, if the branch transaction component script is updated, compiling the updated script to generate a new branch transaction component, and loading the new branch transaction component to replace the original branch transaction component.
In the above example, the Bean is a Groovy Bean; the refresh-check-delay attribute value of the Groovy Bean element is a script refreshing effective period; the component replacement unit compiles the updated script to generate a new branch transaction component, and loads the new branch transaction component to replace the original branch transaction component, including: and acquiring a Groovy Bean identifier with a changed script and an updated script of the Groovy Bean with the identifier by adopting a script factor Postprocessor assembly supporting the Groovy Bean by a Spring container, and loading and initializing the Groovy Bean with the identifier by using the updated script.
Optionally, the replaced branch transaction component increases, decreases, or changes parameters passed through the service interface when the service interface of the participant is called.
Embodiments of the present description provide a computer device that includes a memory and a processor. Wherein the memory has stored thereon a computer program executable by the processor; the processor, when executing the stored computer program, performs the steps of an implementation method of the embodiments of this specification as applied to distributed transaction hot deployment of initiators. For a detailed description of the steps of the implementation method for distributed transaction hot deployment of the initiator, please refer to the previous contents, which are not repeated.
Embodiments of the present specification provide a computer-readable storage medium having stored thereon computer programs which, when executed by a processor, perform the steps of an implementation method of embodiments of the present specification applied to distributed transaction hot deployment of an initiator. For a detailed description of the steps of the implementation method for distributed transaction hot deployment of the initiator, please refer to the previous contents, which are not repeated.
The above description is only exemplary of the present invention and should not be taken as limiting the scope of the present invention, and any modifications, equivalents, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
As will be appreciated by one skilled in the art, embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present description may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.
Claims (12)
1. An implementation method of distributed transaction hot deployment is applied to an initiator, wherein the initiator comprises at least one branch transaction component, each branch transaction component corresponds to at least one participant of the distributed transaction and is used for calling a service interface issued by the corresponding participant, and the method comprises the following steps:
acquiring a script updated by a certain branch transaction component; the branch transaction component is a component for carrying out distributed transaction on an initiator by calling a participant service interface;
generating a new branch transaction component according to the updated script, and replacing the original branch transaction component;
calling a participant service interface corresponding to the branch transaction component by adopting the replaced branch transaction component;
wherein, the obtaining of the updated script of a certain branch transaction component includes: and receiving the updated script of the branch transaction component pushed by the distributed resource management DRM server.
2. The method of claim 1, the branch transaction component is a Java Bean;
generating a new branch transaction component according to the updated script to replace the original branch transaction component, including: after detecting that a certain Bean script is updated, compiling the updated script to generate a new Bean, assembling the new Bean into the context of an initiator, and replacing the original Bean with the same Bean identification.
3. The method of claim 1, wherein generating a new branch transaction component in accordance with the updated script to replace the original branch transaction component comprises: when the script refreshing effective period comes to an end, if the branch transaction component script is updated, compiling the updated script to generate a new branch transaction component, and loading the new branch transaction component to replace the original branch transaction component.
4. The method of claim 3, the branch transaction component is a Groovy Bean; the refresh-check-delay attribute value of the Groovy Bean element is a script refreshing effective period;
the compiling the updated script to generate a new branch transaction component, and loading the new branch transaction component to replace the original branch transaction component, including: acquiring a Groovy Bean identifier with a changed script and an updated script of the Groovy Bean with the identifier by using a script source interface supporting Groovy through a Spring container; and adopting a script factor Postprocessor interface supporting the Groovy Bean to load and initialize the Groovy Bean with the identification by the updated script.
5. The method of claim 1, the replaced branch transaction component increases, decreases, or changes parameters passed through the service interface of the participant when the service interface is invoked.
6. An apparatus for implementing distributed transaction hot deployment, applied to an initiator, where the initiator includes at least one branch transaction component, and each branch transaction component corresponds to at least one participant of the distributed transaction and is used to invoke a service interface issued by the corresponding participant, and the apparatus includes:
the updating script obtaining unit is used for obtaining a script after updating of a certain branch transaction component;
the component replacement unit is used for generating a new branch transaction component according to the updated script and replacing the original branch transaction component;
the component calling unit is used for calling a participant service interface corresponding to the branch transaction component by adopting the replaced branch transaction component; the branch transaction component is a component for carrying out distributed transaction by calling a participant service interface on an initiator;
the update script obtaining unit is specifically configured to: and receiving the updated script of the branch transaction component pushed by the distributed resource management DRM server.
7. The apparatus of claim 6, the branch transaction component is a Java Bean;
the component replacement unit is specifically configured to: after detecting that a certain Bean script is updated, compiling the updated script to generate a new Bean, assembling the new Bean into the context of an initiator, and replacing the original Bean with the same Bean identification.
8. The apparatus of claim 6, the component replacement unit to specifically: when the script refreshing effective period comes to an end, if the branch transaction component script is updated, compiling the updated script to generate a new branch transaction component, and loading the new branch transaction component to replace the original branch transaction component.
9. The apparatus of claim 8, the branch transaction component is a Groovy Bean; the refresh-check-delay attribute value of the Groovy Bean element is a script refreshing effective period;
the component replacement unit compiles the updated script to generate a new branch transaction component, and loads the new branch transaction component to replace the original branch transaction component, including: acquiring a Groovy Bean identifier with a changed script and an updated script of the Groovy Bean with the identifier by using a script source interface supporting Groovy through a Spring container; and adopting a script factor Postprocessor interface supporting the Groovy Bean to load and initialize the Groovy Bean with the identification by the updated script.
10. The apparatus of claim 6, the replaced branch transaction component increases, decreases, or changes parameters passed through the service interface of the participant when the service interface is invoked.
11. A computer device, comprising: a memory and a processor; the memory having stored thereon a computer program executable by the processor; the processor, when executing the computer program, performs the method of any of claims 1 to 5.
12. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810326355.8A CN108733589B (en) | 2018-04-12 | 2018-04-12 | Method and device for realizing distributed transaction hot deployment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810326355.8A CN108733589B (en) | 2018-04-12 | 2018-04-12 | Method and device for realizing distributed transaction hot deployment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108733589A CN108733589A (en) | 2018-11-02 |
| CN108733589B true CN108733589B (en) | 2021-11-02 |
Family
ID=63941380
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810326355.8A Active CN108733589B (en) | 2018-04-12 | 2018-04-12 | Method and device for realizing distributed transaction hot deployment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108733589B (en) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109634655A (en) * | 2018-12-10 | 2019-04-16 | 江苏满运软件科技有限公司 | Variable configuration method based on heat deployment, device, electronic equipment, storage medium |
| CN110321181A (en) * | 2019-06-28 | 2019-10-11 | 阿里巴巴集团控股有限公司 | Event production method and its device under SOA system |
| CN111984294B (en) * | 2020-08-20 | 2024-04-16 | 中国银行股份有限公司 | Service system updating method and device based on Groovy dynamic loading technology |
| CN112765126A (en) * | 2020-12-31 | 2021-05-07 | 金蝶软件（中国）有限公司 | Database transaction management method and device, computer equipment and storage medium |
| CN112995304B (en) * | 2021-02-08 | 2022-09-23 | 中国工商银行股份有限公司 | Method and device for processing routing service node by two-stage distributed transaction |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1677361A (en) * | 2004-03-31 | 2005-10-05 | 华为技术有限公司 | Distributed test assembly frame system and test assembly transparent transmission method |
| CN103617037A (en) * | 2013-11-27 | 2014-03-05 | 张洁 | Developing method for web development system and web development system |
| CN104866341A (en) * | 2015-05-07 | 2015-08-26 | 北京金山安全软件有限公司 | Component upgrading method and device and terminal |
| CN105740019A (en) * | 2016-01-29 | 2016-07-06 | 公安部交通管理科学研究所 | Automatic upgrading and releasing system and method for application software in distributed network environment |
| CN105843638A (en) * | 2016-03-18 | 2016-08-10 | 浪潮软件集团有限公司 | Upgrading and reconstruction method for Spring old version framework |
| CN106227554A (en) * | 2016-07-08 | 2016-12-14 | 百度在线网络技术（北京）有限公司 | A kind of method and apparatus carrying out applying heat renewal in ios system |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10230786B2 (en) * | 2016-02-26 | 2019-03-12 | Red Hat, Inc. | Hot deployment in a distributed cluster system |
-
2018
- 2018-04-12 CN CN201810326355.8A patent/CN108733589B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1677361A (en) * | 2004-03-31 | 2005-10-05 | 华为技术有限公司 | Distributed test assembly frame system and test assembly transparent transmission method |
| CN103617037A (en) * | 2013-11-27 | 2014-03-05 | 张洁 | Developing method for web development system and web development system |
| CN104866341A (en) * | 2015-05-07 | 2015-08-26 | 北京金山安全软件有限公司 | Component upgrading method and device and terminal |
| CN105740019A (en) * | 2016-01-29 | 2016-07-06 | 公安部交通管理科学研究所 | Automatic upgrading and releasing system and method for application software in distributed network environment |
| CN105843638A (en) * | 2016-03-18 | 2016-08-10 | 浪潮软件集团有限公司 | Upgrading and reconstruction method for Spring old version framework |
| CN106227554A (en) * | 2016-07-08 | 2016-12-14 | 百度在线网络技术（北京）有限公司 | A kind of method and apparatus carrying out applying heat renewal in ios system |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108733589A (en) | 2018-11-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108733589B (en) | Method and device for realizing distributed transaction hot deployment | |
| US11853774B2 (en) | Dynamically loaded plugin architecture | |
| US9280338B1 (en) | Dynamic application updates | |
| US8793662B2 (en) | Runtime code hooking for print driver and functionality testing | |
| CN110007980B (en) | Method and device for realizing multi-service server | |
| WO2022016848A1 (en) | Method and apparatus for performing application deployment according to service role | |
| US6112253A (en) | Object-oriented method maintenance mechanism that does not require cessation of the computer system or its programs | |
| US20050086640A1 (en) | Initiating execution of application programs on a data processing arrangement | |
| KR102023223B1 (en) | Dynamic injection of code into running process | |
| US9690567B2 (en) | Runtime detection of software configurations and upgrades | |
| US20080127076A1 (en) | jmx bean custom service extension plugin agent for an application server | |
| Gregersen et al. | Dynamic update of Java applications—balancing change flexibility vs programming transparency | |
| US20040143835A1 (en) | Automatically upgradeable extension of software | |
| US11880674B2 (en) | Adaptive hot reload for class changes | |
| US11880694B2 (en) | System and method for behavior injection in cloud computing platforms or applications | |
| US20200034166A1 (en) | Virtual machine container for applications | |
| CN116049207A (en) | Application SQL script processing method and device, processor and electronic equipment | |
| CN112579099A (en) | Code deployment method and device, storage medium and electronic equipment | |
| CN110083366B (en) | Application running environment generation method and device, computing equipment and storage medium | |
| CN111782335A (en) | Extended application mechanism through in-process operating system | |
| CN110334031B (en) | Memory allocation code detection method and device, computer equipment and storage medium | |
| CN113867776A (en) | Method and device for publishing middle station application, electronic equipment and storage medium | |
| CN112134922B (en) | Service calling method and device based on micro-service and storage medium | |
| CN110275710B (en) | Java local interface consistency checking method and system, storage medium and terminal | |
| CN112463262A (en) | Android system GPS module self-adaption method and terminal |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20201022 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20201022 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Applicant before: Alibaba Group Holding Ltd. |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |