On teh way

Deep in Transaction (2) In last blog, we have mentioned that the job of a transaction is to keep state consistent when there are multiple transactions access object concurrent; there are server crash/failure; And we have discussed how a transaction will handle crash of server & client in deign level. Today, we focus on how transaction make objects consistent when multiple client access them, i.e. the Concurrency Control of transaction. Why Transaction Before dive into how to do it, we need to understand why we need it, or what problems may arise when concurrent access happens and we don’t control them. Access at Same Time We will illustrate two famous problems of concurrent problems by bank deposit/withdraw examples. Lost Update Transaction T Transaction U balance=b.getBalance(); balance=b.getBalance(); b.setBalance(balance+10); b.setBalance(balance+20); b 10 b 10 balance=b.getBalance(); 10 balance=b.getBalance();

Deep in Transaction (1) When it comes transaction, we think of ACID property, we think of a bunch of actions which should be done in all or nothing. Atomicity: guarantees that each transaction is treated as a single “unit” Consistency: ensures that a transaction can only bring the database from one valid state to another Isolation: ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially Durability: guarantees that once a transaction has been committed, it will remain committed even in the case of a system failure It seems all four rules of ACID are the equally property for a transaction, but it is not. Why We Need Transaction To make it clear, the very first goal of transactions is to ensure that all of the objects managed by a server remain in a consistent state when they are accessed by multiple transactions and in the presence of server crashes.

Compile Java Using Java Recently, we decided to refactor the Filter module of [Syncer](https://github.com/zzt93/syncer/) , which is used to be implemented by Spring EL . We want to refactor it for three reasons: The Spring EL is not so fast compared with native Java code; The config specified by Spring EL is rather hard to write and maintain; The config expression defined by myself is rather limited in supported syntax; So, we came up with two options to upgrade it: First, we upgrade config expression with better hierarchy and support more powerful expression; Second, we introduced the Java code to do the config; The first option is not related with this post, so we will skip to next one: config application using Java code. Background In syncer, we listen on change of different input , and manipulate the data via filter module, then output to target output like following: version : 1.2 consumerId : sample1 input : masters :