1. 首頁
  2. 問答
  3. DB2 BIGINT id生成

DB2 BIGINT id生成

2011-05-25 83 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年是長期的

來源

2011-05-25 Troydm

回答

1

這些ID可能不是唯一的。如果在不同的JVM中有兩個會話同時生成ID，毫秒分辨率還不足以確保您獲得唯一的ID。

考慮使用內置的UUID。但是，這會產生一個128位的UUID。但即使在不同的JVM中，它也確保了獨特性。

還有另一個堆棧溢出的討論，它解決了如何對 generate UUID of long type。

來源

2011-05-25 07:36:06 stafford

+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（典型月份的天數）

來源

2011-05-25 08:11:18

+0

，並且你對日期是正確的，但它在上下文中無關緊要問題 – Troydm 2011-05-25 08:13:07

相關問題

 相關問題