On teh way

Recently, I am handling the graceful shutdown of Syncer . In the process of implementation, I was surprised by some counterintuitive part of Java. Let’s go on and see whether you know it. Thread States The following enumerations are states of Java Thread which is cited from Java documentation: NEW A thread that has not yet started is in this state. RUNNABLE A thread executing in the Java virtual machine is in this state. BLOCKED A thread that is blocked waiting for a monitor lock is in this state. WAITING A thread that is waiting indefinitely for another thread to perform a particular action is in this state. TIMED_WAITING A thread that is waiting for another thread to perform an action for up to a specified waiting time is in this state. TERMINATED A thread that has exited is in this state. The naming of state is fine, but those description is not clear enough though: What a Thread 's state if it blocked in IO operation? What a Thread 's state if it calle...

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 : ...

Deep in Transaction (3) In last blog, we talk about four kinds of problems when we lack of a reasonable implementation of transaction: Lost Update; Inconsistent Retrieval; Dirty Read; Premature Write; Today, we focus on how we make it. How The first tool we can come up with when dealing with concurrent access problem is locking. Besides it, we will also see how optimistic concurrency control and timestamp order make it. Lock The basic idea of lock is very simple: when multiple clients want to access same object, only one client will get the lock and continue, other clients will wait until lock is free – Serialization between multiple clients. In the context of Transaction , lock is relative complex. Two Phase Locking We have introduced the conflict operations between transactions, and in order to solve it we can make transaction serially equivalent (or totally serialization). In details, Serial Equivalence requires that all of a transaction’s ...

Deploy to Maven Central Recently, we need to deploy some jar to maven for open source reason, so we through some trial and errors finally make it. This blog is for future reader for review. Registration Introduction to Sonatype OSSRH Sonatype OSSRH uses Nexus to provide deployment service for open source project, and this repo is called maven central, in which OSSRH all us to submit and download binary jar. Registration Create an account of JIRA Create a new issue about your deploy request Notice : Only when this issue’s state change to RESOLVED , we can start to deploy jar; If we deploy on behalf of yourself, we should be careful about groupId : e.g. our project is put on github called syncer , so groupId can be com.github.zzt93 ; Update POM After the registration and issue resolved, we need to add more info in pom to do the deployment: name , description , url , groupId , artifactId , version , license , developers , scm < name > ${projec...

微信支付的坑（2） 在 上一篇支付相关的博客中 ，我们介绍了接入支付宝和微信支付的两个大坑，一个是沙箱测试环境的搭建，第二个是回调接口的编写。在这篇中，我们将继续深入。 如果你需要接入微信手机端的网页支付的话，光接入“H5支付”产品是不够的，因为H5支付只能用于微信外的手机网页支付，如果想要在微信内扫一扫，打开页面然后支付，需要使用“公众号支付”产品。而“公众号支付”产品要比H5支付复杂许多。 首先，在H5支付下单后，后端只要返回一个带有回调的链接就可以实现唤起微信支付，并且在支付完成后回到相应的页面。而公众号支付支付需要前端拿到后端的返回值（prepare_id）之后，再进行一次带有签名的请求。由于不可能将秘钥等敏感数据传递或放置于前端，所以需要后端进行 请求的签名 ，然后将所有参数发送到前端，由前端请求。 而且，在初识请求后端生成prepare_id到时候，需要一个不同的参数，即openid。openid是一个用户的标识，但是这个标识不是一个全局的userid，而是一个用户相对于某个微信应用（appid）生成的id。为了获取openid需要使用微信的 oauth鉴权接口 ，不过在进行开发之前，需要进行一系列的配置（不得不说，微信的配置要比支付宝繁杂很多。并且就接口友好性、SDK支持，社区和官方帮助等方面的对比，支付宝的开放性，要比微信好很多） 设置支付目录 在微信商户平台（ pay.weixin.qq.com ）设置您的公众号支付支付目录，设置路径：商户平台–>产品中心–>开发配置，如图7.7所示。公众号支付在请求支付的时候会校验请求来源是否有在商户平台做了配置，所以必须确保支付目录已经正确的被配置，否则将验证失败，请求支付不成功。 现在已经支持配置根目录，配置后有一定的生效时间，一般5分钟内生效 需要注意的是公众平台有时候设置的是域名（url），不能加协议，而有时候填写的是链接，要加协议（http或https） 设置授权回调域名 除了设置支付目录，为了获取openid，需要设置授权回调域名( 公众平台 ->设置->公众号设置->网页授权域名): 开发公众号支付时，在统一下单接口中要求必传用户openid，而获取openid则需要您在公众平台设置获取openid的域...