In computing, the X/Open XA standard (short for “eXtended Architecture”) is a specification released in 1991[1] by X/Open (which later merged with The Open Group) for distributed transaction processing (DTP).
The goal of XA is to guarantee atomicity in “global transactions” that are executed across heterogeneous components. A transaction is a unit of work such as transferring money from one person to another. Distributed transactions update multiple data stores (such as databases, application servers, message queues, transactional caches, etc.) To guarantee integrity, XA uses a two-phase commit (2PC) to ensure that all of a transaction’s changes either take effect (commit) or do not (roll back), i.e., atomically.
XA Architecture
Specifically, XA describes the interface between a global transaction manager and a specific application. An application that wants to use XA engages an XA transaction manager using a library or separate service. The transaction manager tracks the participants in the transaction (i.e. the various data stores to which the application writes), and works with them to carry out the two-phase commit. In other words, the XA transaction manager is separate from an application’s interactions with servers. XA maintains a log of its decisions to commit or roll back, which it can use to recover in case of a system outage.[1]
Many software vendors support XA (meaning the software can participate in XA transactions), including a variety of relational databases and message brokers.[1]
MHA(Master High Availability)目前在MySQL高可用方面是一个相对成熟的解决方案,它由日本人youshimaton开发,是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中,MHA能做到0~30秒之内自动完成数据库的故障切换操作,并且在进行故障切换的过程中,MHA能最大程度上保证数据库的一致性。
[$ /home/w/percona/percona-toolkit-3.0.13/bin]$ ./pt-fingerprint --query "select a, b, c from users where id = 500" select a, b, c from users where id = ? [$ /home/w/percona/percona-toolkit-3.0.13/bin]$ ./pt-fingerprint --query "update test set a =1 , b=2 where id = 3" update testset a =? , b=? where id = ? [$ /home/w/percona/percona-toolkit-3.0.13/bin]$ ./pt-fingerprint --query "update test set a =1 , b=2 where id = 5" update testset a =? , b=? where id = ? [$ /home/w/percona/percona-toolkit-3.0.13/bin]$ [$ /home/w/percona/percona-toolkit-3.0.13/bin]$ ./pt-fingerprint --query "insert into a(id) values (1)" insert into a(id) values(?+) [$ /home/w/percona/percona-toolkit-3.0.13/bin]$ ./pt-fingerprint --query "insert into a(id) values (2)" insert into a(id) values(?+) [$ /home/w/percona/percona-toolkit-3.0.13/bin]$ ./pt-fingerprint --query "delete from test where id = 2" delete from testwhere id = ? [$ /home/w/percona/percona-toolkit-3.0.13/bin]$ ./pt-fingerprint --query "delete from test where id = 3" delete from testwhere id = ? [$ /home/w/percona/percona-toolkit-3.0.13/bin]$
@Test publicvoidexecute(){ ShellCommandExecutor shellCommandExecutor = new ShellCommandExecutor();
for (int j = 0; j < 20; j++) { long start = System.currentTimeMillis(); for (int i = 0; i < 100; i++) { ShellCommandExecInputer commandExecInputer = new ShellCommandExecInputer(); commandExecInputer.setCommand("./pt-fingerprint --query \"select a, b, c from users where id = 500\""); commandExecInputer.setCommandExecDir("/Users/rollenholt/Downloads/percona/percona-toolkit-3.0.13/bin"); ShellCommandExecResult execResult = shellCommandExecutor.execute(commandExecInputer); Assert.assertTrue(execResult.isOk()); } long end = System.currentTimeMillis(); System.out.println((end - start) ); } }
Each object is associated with a monitor. A monitor is locked if and only if it has an owner. The thread that executes monitorenter attempts to gain ownership of the monitor associated with objectref, as follows:
• If the entry count of the monitor associated with objectref is zero, the thread enters the monitor and sets its entry count to one. The thread is then the owner of the monitor. • If the thread already owns the monitor associated with objectref, it reenters the monitor, incrementing its entry count. • If another thread already owns the monitor associated with objectref, the thread blocks until the monitor’s entry count is zero, then tries again to gain ownership.
The thread that executes monitorexit must be the owner of the monitor associated with the instance referenced by objectref. The thread decrements the entry count of the monitor associated with objectref. If as a result the value of the entry count is zero, the thread exits the monitor and is no longer its owner. Other threads that are blocking to enter the monitor are allowed to attempt to do so.