Hibernate的increment主键生成机制带来的问题(转)

在网站运行在apache和tomcat的负载均衡之后，总是出现一些奇怪的问题。开始有一些Duplicate entry的错误，但没在意。
      今天又看了程序运行的错误信息，发现几乎都是Duplicate entry错误，集中出现在insert数据库的时候，insert user，insert message。看了Message类的主键生成是increment类型，看了看Hibernate的源代码，发现对应increment主键生成器的org.hibernate.id.IncrementGenerator 类里面，是使用select max( columnName ) from tableName的方式来获取。原来的程序一直运行很好，但是在用两个Tomcat来负载均衡后却出现问题。为什么？ IncrementGenerator类里面的generate()方法虽然被声明成了synchronized，但现在两个Tomcat分别运行在两台服务器的两个独立的Java虚拟机里，显然问题在这里，synchronized只能在一个独立的Java虚拟机内部有效。所以，在两个Tomcat 中用select max同时取主键，就相当于在没有synchronized的保护下，并发时就会取出相同的值，再insert就会发生dumplicate entry的错误。
      后来查看Hibernate的Reference中也提到，increment不要再集群下使用。
      问题找到了，解决的办法也很简单，就是使用MySQL自己的auto_increment功能来产生主键。只需将所有Hibernate映射文件中的 increment改为native或者identity。并将数据库的主键加上auto_increment属性。
      查看MySQL 5.0的文档，在14.2.6.3中介绍说：
14.2.6.3. How AUTO_INCREMENT Columns Work in InnoDB
If you specify an AUTO_INCREMENT column for an InnoDB table, the table handle in the InnoDB data dictionary contains a special counter called the auto-increment counter that is used in assigning new values for the column. This counter is stored only in main memory, not on disk.
InnoDB uses the following algorithm to initialize the auto-increment counter for a table T that contains an AUTO_INCREMENT column named ai_col: After a server startup, for the first insert into a table T, InnoDB executes the equivalent of this statement:

SELECT MAX(ai_col) FROM T FOR UPDATE;

看来在给数据库主键加上auto_increment的属性后，还要重新启动一下MySQL，这样才能保证所有的auto_increment被初始化正确。
好了，开始修改，别忘了先关掉所有的Tomcat！
问题解决后的感想：

Hibernate的主键生成虽然支持很多种数据库独有的increment方式，还有他自己的select max实现的increment方式，其实这些都不是很好，假如将来真的要切换数据库，并且是在集群下运行程序，某种数据库独有的increment和 select max方式的increment都会带来问题。
Hibernate中唯一一种最简单通用的主键生成器就是uuid。虽然是个32位难读的长字符串，但是它没有跨数据库的问题，将来切换数据库极其简单方便。推荐使用！！