2011-05-25 177 views
2

我有以下类加载到DB2 9.7.4 Express-C中,用于产生用于IDS行DB2 BIGINT id生成

public class Int64UUID { 

    public static final long dx = 30*386*12*30*24*3600*1000; // starting at 2000 year 
    public static long lastUUID = System.currentTimeMillis() - dx; 

    public static synchronized long random(){ 
     long uuid = System.currentTimeMillis() - dx; 
     while(uuid == lastUUID) 
      uuid = System.currentTimeMillis() - dx; 
     lastUUID = uuid; 
     return uuid; 
    } 

    public static void main(String[] args) { 
     System.out.println(Int64UUID.random()); 
    } 

} 

和下面的函数使用它

CREATE FUNCTION "MYSCHEMA"."INT64_GUID" () 
    RETURNS BIGINT 
    SPECIFIC "SQL110520165927000" 
    LANGUAGE JAVA 
    PARAMETER STYLE JAVA 
    EXTERNAL NAME 'Int64UUID.random' 
    NOT DETERMINISTIC 
    NO EXTERNAL ACTION 
    NO SQL 
    CALLED ON NULL INPUT 
    DISALLOW PARALLEL; 

将生成的ID使用这些函数在同步过程中在db2会话中是唯一的,这是一个更好的替代方法,我知道这些id将在未来60年内过期,但60年是长期的

回答

1

这些ID可能不是唯一的。如果在不同的JVM中有两个会话同时生成ID,毫秒分辨率还不足以确保您获得唯一的ID。

考虑使用内置的UUID。但是,这会产生一个128位的UUID。但即使在不同的JVM中,它也确保了独特性。

还有另一个堆栈溢出的讨论,它解决了如何对 generate UUID of long type

+1

是的,但为什么我会在一个DB2实例的不同会话中有两个JVM? – Troydm 2011-05-25 08:07:08

+0

您可能是对的,但我不确定DB2如何管理每个会话的JVM。然而,接下来你需要担心的是你的代码在每次需要生成一个ID时可能会阻塞1毫秒(在这段时间内)。提到的适当的UUID功能没有这个问题。 – stafford 2011-05-25 08:32:18

+0

是的,但1毫秒在我的项目中是如此无关紧要,我认为平均每秒生成uuid请求不会超过其长(64位整数)的10 – Troydm 2011-05-25 09:28:36

0

dx值看起来有点随机。它太大而不适合int,并且会超过流量,但它看起来不正确。你有30 *(30年)* 386(不知道这是否应该是356)* 12(每年的月数)* 30(典型月份的天数)

+0

,并且你对日期是正确的,但它在上下文中无关紧要问题 – Troydm 2011-05-25 08:13:07