百川进入容易，带数据出来难

工具是拿来用的，不是用来供的。
两年用坏了就值了，三年用坏就赚了。

没事，会赔偿你 memcached 使用费用的 100 倍的，逃

自己的路自己走

干吗要买水果？

别浪费自己的时间

楼主是处女座

林昊
曾宪杰

此外，就算弄个假的，或者延时的，也是可以的嘛。

看上去是那个样子，差不多数据就好了

逃~

为啥不弄台机器，搞一个 table ，用户 id 映射到 table index 上面

上线，异步消息， table[index] = 1, 下线，异步消息， table[index] = 0

60 秒做一次 table 计数

gitlab 本身是自带 nginx 的，你要关闭原来那个，然后在自己的 nginx 上配上 passenger 什么的

总之，你文档没读 -_-!!!

@odirus 你说的两个问题，我感觉可以一起来讲

CheckedException 出来，就像你说的，业务方（上层调用者）需要知道有可能出现这个异常，你需要做下一步处理。

但是实际情况是，上层调用者很少去关心这个很可能出现的异常，因为还有上层，一个 Service 里面调用很多个 DAO 嘛。不过这个要具体的看你们的业务。


再说如何处理所有类型的 Exception ，比方说现在很多 App 或者 Web 后台都是接入 Java 的，我当然不希望我的异常被用户感知到，那现在的容器都有一个全局 Catch Exception 的功能， Spring 有， Jersey 有， Spring boot 有， Grails 都有。我们会利用这个功能 Catch 所有 Exception ，返回 App 能理解的 JSON （比如网络异常请稍后再试）或者 Web 直接跳转到 500 页面，并消息通知给开发者。

Checked Exception ，也就是你一个业务流转的方式，比方说，如果你有事务超时的异常的时候，你会发消息给到你的监控，等等，这时候你自己要 catch 住，这是你要 hold 住的地方，然后再 Runtime 出去。

我认为任何异常都应该最后 throw 出去

但是大部分作为一个公共组件，特别是内部使用的时候，也就是你用一下我的 SQL ，他也需要用一下这个 SQL ，我就打个包给大家用。我就建议全部变成 Runtime Exception 吧。

为什么这么说？

异常比方说：
索引问题
SQL 语句问题
事务锁超时等等

这一系列都属于 BUG ，这类 SQL 本来就不应该在代码中出现，也不是你的使用方，或者叫做业务方，他们需要关心的。出现了异常，就去修吧，把 log 打到单独的文件里面。

此外， 还有一些通用的规范，比方说
数据 insert or update ，更新成功返回 1 ，没有成功返回 0
findOne ，找到返回 obj ，没有找到 返回 null
findList ， 没有找到返回 empty list ，绝对不能成为 null

我注意到你在用 mybatis ，我十分推荐你使用 MyBatis Generator ，这样可以帮助你少写很多代码。

最后，我是 Hibernate 的忠实粉丝，谢谢