Redis Series Learning (iii) Java API access and transaction __redis

	Redis Series Learning (iii) Java API access and transactions



	




One introduction two business examples supplement three watch order

first, the introduction

This article provides examples of transactions in the article "Redis Series Learning (iii) Java API access and transactions" , supplementary

No business.

private void Testtransaction () {
        System.out.println ("====================== test transaction ==========================");
        Jedis.set ("Sex", "man");
        JEDIS.INCR ("Sex");
        Jedis.set ("Hello", "World");
    }

The results are as follows:

Database view:

First add "Sex=man" data, and then call the "incr" command to do plus 1 operations, because the value "man" is not an integral type, so plus 1 operation has a run-time error, the wrong command will not continue to execute, we see the run-time error, but still successful.
What if you add a transaction. The previous article said "Run-time error, even if the error occurred, the modified value does not roll back, and the following command will continue to execute", verify below.

private void Testtransaction () {
        System.out.println ("====================== test transaction ==========================");
        Transaction Transaction = Jedis.multi ();
        Transaction.set ("Sex", "man");
        TRANSACTION.INCR ("Sex");
        Transaction.set ("Hello", "World");
        Transaction.exec ();
    }

The IDE results are shown below:

Middle "transaction.incr" ("Sex"); " The command returned an execution error message, but the following command continued.

The database is shown below

Although a run-time error occurred, no exception was reported, and subsequent commands continue to execute where the error occurred.

An error that occurs at run time, even if the error occurs (Redis received and executed without treating it as an error), and subsequent commands continue to execute. iii. Watch order

The watch command can monitor one or more keys, and once a key is modified (or deleted), subsequent transactions are not executed. The monitor lasts until the EXEC command (the commands in the transaction are executed after exec, so you can modify the key values of watch monitoring after the multi command)
Example:

private void Testtransaction () {
        System.out.println ("====================== test transaction ==========================");
        Jedis.watch ("Sex");
        Jedis.set ("Sex", "man2");
        Transaction Transaction = Jedis.multi ();
        Transaction.set ("Country", "the");
        Transaction.set ("Sex", "female");
        Transaction.set ("Hello", "World");
        list<object> results = transaction.exec ();
        System.out.println (Results.tostring ());
    }

The database results are shown below

In the example, the raw data is "Sex=man", the code uses watch to monitor the sex field, and then modifies Sex=man2, although the set is "female" in the transaction command queue, but the result is sex=man2. By some we can know that because the sex was modified before the transaction was opened, all the commands in the transaction were not executed, emphasizing that " all commands in the transaction queue will not be executed "