SQLAlchemy 的 Identity Map 和 Cache 造成的 add 失败

April 23, 2016

标题剧透预警，然而已经晚了 :)

事情是这样的：这两天在写某 Flask App 的用户模块，访问邮箱验证邮件里的链接时，SQLAlchemy 在 db.session.add(user) 时有一定几率抛出异常：

AssertionError: A conflicting state is already present in the identity map for key (, (UUID('12345678-1234-1234-1234-123456789abc'),))

重现模式也很奇怪，同一个链接，首次访问时几乎都是异常，而刷新一下重新访问，一切就平平稳稳通过了。但是如果开新的浏览器（新的隐身窗口）访问，似乎无论是不是首次访问都没有问题。

问题是什么

断言内容直译是「目前的 Identity Map 中已存在与之冲突的状态」。

SQLAlchemy 是数据库和 Python 的中间层，Identity Map 即数据库对象与 Python 对象的映射表。我们之所以可以做这样的判断：

new_user = User(id=42)
db.session.add(new_user)
user = User.query.get(42)
assert user is new_user

就是 Identity Map 的功劳。

如果试图往 Identity Map 里加入两个不同的 Python 对象，但这两个 Python 对象都映射到同一个数据库对象，自然就不科学了，因为打破了其中的不变量。

foo = Model(id=42)
db.session.add(foo)  # OK
bar = Model(id=42)
db.session.add(bar)  # Fail

问题的成因

系统中有一个 get_user_by_id 的函数用以从数据库查找用户。这个函数额外加了个自己实现的 @cache 装饰器，用 Redis 做了缓存。

发送验证邮件时，因为其它部分的逻辑对用户信息做了修改，导致缓存被清空。于是下一次对 get_user_by_id 的调用一定会走数据库。

点击邮件中的验证链接后，访问验证页面。由于在 app.before_request 中插入了用 Session 中的 user_id 通过 get_user_by_id 获取用户信息的操作，做了数据库访问， Identity Map 中就保存了这一份 UserModel，暂且称作 A。

正式的验证页面逻辑，需要从验证链接中提取到这条链接对应的 user_id，继而通过 get_user_by_id 获得对应的 UserModel，此时的 UserModel 是从 Redis 中反序列化而来的，暂且称作 B。

A 和 B 虽然指向同一个数据库对象，但其实是不同的 Python 对象。通过 db.session.add 把 B 加入 Session，就会与 Identity Map 里原有的 A 发生冲突。

所以第二次访问该链接，由于都是从 Cache 加载的对象，Identity Map 一直是空的，就不会有如何问题；打开新浏览器，由于没有登录，也不会触发 app.before_request 中的数据库操作，所以也不会有问题。

问题的解决？

有一个解决方法，是新开一个 get_user_by_id_for_update(user_id) 从数据库加载，与此同时，正好可以在该函数内部给数据库请求加上 with_for_update() 给该记录加锁。

其它的选项还包括：

在 @cache 里为带 Cache 的函数都加上 force 参数的支持
- 个人觉得，force 参数的「跳过缓存」语义暴露了实现细节，相比之下， get_model_by_id_for_update 的「修改」语义比它高到不知道哪里去了
统一把 update_model(model, **kwargs) 改成 update_model(model_id, **kwargs) 的形式，在内部做数据库查询
- 个人觉得，将 update_model 改为接受 model_id 的做法则有点本末倒置的意思

还是用 `merge` 更好啦

距离原来这篇博客发出已经一年多了，期间一直在遵循着上面所说的解决办法。但最近因为需要自己为 SQLAlchemy 封装 Write-through Cache 的轮子，又仔细阅读了 SQLAlchemy 的文档，发现在出现此种状况也可以选择使用 session.merge(obj, load=False) 将对象直接放入本 session 的 identity map 中。

session.merge 会首先根据对象的主键在 identity map 中查找对象，如果没有找到，则从数据库中加载一个进来。然后，会将传入对象的状态同步给 identity map 中的对象。

添加 load=False 参数，就会跳过「从数据库中加载一个」的步骤，直接在 identity map 中新建一个对象。由于对对象的状态有严格要求，官方文档中只推荐从缓存中加载时使用。不过这正是我们所需要的，哈哈。

以上。

《C++ 并发编程实战》读书笔记：管理线程

October 25, 2015

最近终于找到本有兴趣的书啦，就是这本《C++ 并发编程实战》。我会找一些自己觉得没想到、好玩、或者有自己想法的地方整理下。

顺带吐个槽：In Action 系列的封面人物真心诡异，还是 O'reilly 萌萌哒的奇怪可爱小动物看着顺心。

`join()` 的异常安全

std::thread 要求在析构函数被调用时，该对象必须没有与之相关联的线程，否系统分分钟自尽给你看（调用 std::terminate()）。

一般情况下，我们主要需要注意的地方是析构前对 join() 或者 detach() 的调用。如果要分离线程，线程启动后就可以立即调用 detach()，基本不会带来什么问题。而 join() 则没法立即调用，这样就会带来可能会被忽视的异常安全问题：线程启动后，如果某处抛出异常，可能把本应执行的 join() 跳过，导致程序自行退出。

void foo()
{
    std::thread t(thread_func);
    do_something();  // 如果抛出异常，就可能把下面的 join() 跳过
    t.join();
}

把 do_something(); 用 try / catch 包裹起来，并在 catch 里调 t.join() 最后把异常重新 throw 出去的方案固然可行，但对于 C++ 而言，更好的方案是 RAII：

class thread_guard
{
public:
    explicit thread_guard(std::thread& t)
        : thread_(t)
    {
    }

    ~thread_guard()
    {
        if (thread_.joinable()) {  // join() 前对象必须满足 joinable
            thread_.join();
        }
    }

    thread_guard(thread_guard const&) = delete;
    thread_guard& operator=(thread_guard const&) = delete;

private:
    std::thread& thread_;
};

void foo()
{
    std::thread t(thread_func);
    thread_guard g(t);

    do_something();
}

当然你也可以考虑把 std::thread 移动进去而不是传引用，书里管那种东西叫 scoped_thread，调用时不必为 std::thread 对象单独开一个名字。

线程传参二三事

给线程函数传参是通过 std::thread 的构造函数完成的，其原理与 std::bind 类似。所有参数先在当前线程被复制 / 移动到对象内部，然后在新线程中完成对线程函数的调用。

这两步的划分会导致会被一些人说「坑」（虽然实际上是他们自己没注意）。

比如从「被复制」到「实际调用线程函数」之间可能并不连续，那么被复制的参数届时是否还有效就可能成为问题，例如：

void thread_func(std::string const& s);

void foo(int bar)
{
    char buffer[1024];
    sprintf(buffer, "%d", bar);
    std::thread t(thread_func, buffer);
    t.detach();
}

前面说过构造函数仅负责原样复制 / 移动参数，所以 char * 到 std::string 的转换是在新线程中的第二步时做的，于是例子中 t 对象构造函数暂存的其实是指向栈上的 buffer 的指针。而由于 detach()，foo 返回后可能新线程还未正式启动。如果 thread_func 真正被调用时 foo 已经返回，那么这个指针参数就无效了。

一个解法是把代码改成 std::thread t(thread_func, std::string(buffer));这样构造函数就会把实参 std::string 移动进去（即便在 std::string 无法移动只能复制的平行宇宙，这样做也是安全的）。

再见 ShadowSocks

August 22, 2015

再过十几天，就是世界反法西斯战争胜利纪念日了。今天，ShadowSocks 在 GitHub 的相关仓库被勒令删除代码，停止官方维护，V2EX 和知乎上相关的内容也都被删了，可见这是一个同样值得纪念的日子。

说来，如果不是它，我估计现在还没开始用 Python 呢。要知道学习一门语言，学以致用的需求是很重要的。光头脑发热「我要学 Python」，看个语法，写点 Hello World 之类的，过几天估计就忘了。所幸当时 ShadowSocks 横空出世，给我的感觉是「居然寥寥数行（至少发布之初是这样）就把事情办妥了」「只要查查文档，理解起来应该很快吧」。于是为了理解代码，各种对照着翻文档，看语法，当时还写了一篇博客记录了下笔记。后来的一段时间，写 Python 不知道该用什么风格，也拿 ShadowSocks 的代码来模仿。

话说回来，现在这么多人在用 ShadowSocks，被封其实也是情理之中的事情。如果还能找到 V2EX 上初版 ShadowSocks 的帖子的话，应该可以看到作者当时的想法大致可以总结为：

公布一个自用的梯子，供大家参考
大家用不同的协议，更不容易被封

我觉得后者应该才是精华，可惜实际却很少有人在意。最初只提供傻傻的 Table 加密的一个原因，或许是「它只是一个用来抛砖引玉的 Demo」。或许理想的做法是每个人 Fork 并创造自己的加密手段甚至协议，在小范围内使用。然而更多的人（包括我）选择了直接使用，继而推动 ShadowSocks 本身的复杂化，变成了一个可以让人考虑让它失败的单点。

有点语无伦次。Anyway，谢谢 @clowwindy，辛苦了。

SwipeRefreshLayout 及 Otto 的多线程使用

March 22, 2015

前几周周末百无聊赖，决定利用周末开始一个开发 Android 微博客户端的漫长路程。主要是为了熟悉下 Android Studio 和「更 Android 的网络通信方式」。这周末由于公司项目的事情，没什么空搞这货，只给时间线加了一个下拉刷新的功能。

`SwipeRefreshLayout`

光是下拉刷新的话，其实用不着第三方库，安卓自带就有一个工具类 SwipeRefreshLayout，全名唤作 android.support.v4.widget.SwipeRefreshLayout，可以用作一个可滚动的视图（比如 ScrollView、ListView）的容器，从而为这个视图提供下拉刷新功能。而且理论上根据系统的不同会有不同的表现形式，比如早期的就是 ActionBar 下边缘的横线动画，Material Design 后则是下拉的小圆形动画。

首先在 Gradle 中需要加入对 Support Library v4 的引用：

compile 'com.android.support:support-v4:21.0.0'

当然如果你的工程中已经间接引用了的话也可以不写，比如 v7 就依赖于 v4。

顾名思义，SwipeRefreshLayout 是一种 Layout，可以直接在 XML 文件里用，比如：

<android.support.v4.widget.SwipeRefreshLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/swipe_layout"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <ListView
        android:id="@+id/listview_timeline"
        android:layout_width="match_parent"
        android:layout_height="match_parent" />
</android.support.v4.widget.SwipeRefreshLayout>

此时，如果把 listview_timeline 拉过头，就会触发 SwipeRefreshLayout 的 onRefresh 事件，并在界面上显示加载动画。

通过为 SwipeRefreshLayout 设置 setOnRefreshListener，即可监听刷新事件，重新加载数据。加载完成后，调用 setRefreshing(false) 即可终止刷新动画。

当然写完你就会发现这个刷新图标默认是纯黑色箭头，和我们在 Google+ 以及最近更新的 Chrome 里看到的画风不一样啊。实际上用 setColorSchemeResources 方法就可以为这个动画设置一系列颜色了。

Otto 的跨线程调用

因为我的客户端是在 Service 中请求时间线的，即在 Activity 中触发下拉刷新后，是直接开个新的 Service 去做网络请求。如果要跨组件传递「刷新完成」这样的消息，作为一个新手的我感觉会非常复杂。于是就想起来用 Otto。

Otto 是 Square 公司开源的一个事件总线库（Event Bus）。顺带说一句 Square 公司（不是 Enix 的那个 Square ;)）贡献了很多优质精巧的 Android 开源库，比如 Picasso 和 Retrofit。

用起来大致就是先全局定一个 Bus 对象，比如写一个单例 BusProvider；再为每个事件定义一个类，比如 TimelineUpdatedEvent（空类即可）；最后就可以在事件生成处——比如 Service 里——写：

BusProvider.getInstance().post(new TimelineUpdatedEvent());

而在事件接收处——比如 Activity 里——写：

@Override
public void onPause() {
    super.onPause();
    BusProvider.getInstance().unregister(this);
}

@Override
public void onResume() {
    super.onResume();
    BusProvider.getInstance().register(this);
}

@Subscribe
public void onTimelineUpdated(TimelineUpdatedEvent event) {
    // 时间线已更新，停止刷新动画
}

然而光这样做却有一个问题：Otto 为了保持简洁，要求所有 post 发生在主线程中，而在 Service 中调用显然不在主线程，从而会导致抛出异常。所幸我们可以用 Android 的 Handler 和 Looper 在 Otto 默认的 Bus 周围再封装一层：

public class MainThreadBus extends Bus {
    private final Handler handler = new Handler(Looper.getMainLooper());

    @Override
    public void post(final Object event) {
        if (Looper.myLooper() == Looper.getMainLooper()) {
           super.post(event);
       } else {
            handler.post(new Runnable() {
                @Override
                public void run() {
                    MainThreadBus.super.post(event);
                }
            });
        }
    }
}

思路很简单，post 前先检查自己是否在主线程，如果不是，让关联到主线程的 Handler 去调用原来的 post。

那么 C 语言也可能有类了哟

October 2, 2014

今天看到 C 语言委员会的提案 N1875，顿时有种「卧槽」的感觉，因为它的标题是：Adding classes to C。这要是通过了，那可真就变成名副其实的 C with Classes 了呀～

纵观提案全文，主要从 C++ 中吸收「类」的概念和用法，但是没有虚函数之类的东西。如果算上单独的「访问限制符」、「单一继承」提案，一个 C 语言的类，很可能类似于：

class Car: public Vehicle
{
public:  // 这是单独的另一个提案引入的
    // 构造函数
    initCar() {
        initVehicle();  // 需要显式调用父类构造函数
        countWheels_ = 4;
    }

    // 构造函数
    initCar(int speedMax, int countWheels) {
        initVehicle(speedMax);  // 需要显式调用父类构造函数
        countWheels_ = countWheels;
    }

    // 析构函数
    deleteCar() {
        deleteVehicle();  // 需要显式调用父类析构函数
    }

    int getWheelsCount() const {    // 也有 const 哟
        return this->countWheels_;  // 也有 this 指针
    }

private:
    int countWheels_;
};

使用时，构造写法有点奇怪，也没说构造失败会怎样，析构也需要手动显式调用：

Car car;  // 相当于 initCar()
Car tank.initCar(80, 16);

tank.deleteCar();  // 析构函数需要显式调用
car.deleteCar();

从目前的样子看，这样的「类」更类似于语法糖。当然，这只是个提案而已，会不会最终被批准，还得拭目以待。

以上。

TimothyQiu's Blog

keep it simple stupid

SQLAlchemy 的 Identity Map 和 Cache 造成的 add 失败

问题是什么

问题的成因

问题的解决？

还是用 `merge` 更好啦

《C++ 并发编程实战》读书笔记：管理线程

`join()` 的异常安全

线程传参二三事

再见 ShadowSocks

SwipeRefreshLayout 及 Otto 的多线程使用

`SwipeRefreshLayout`

Otto 的跨线程调用

那么 C 语言也可能有类了哟

问题是什么

问题的成因

问题的解决？

还是用 merge 更好啦

join() 的异常安全

线程传参二三事

SwipeRefreshLayout

Otto 的跨线程调用

还是用 `merge` 更好啦

`join()` 的异常安全

`SwipeRefreshLayout`