Если функция генерирующая uuid в java? 

http://www.google.de/search?q=java+uuid+ge...Suche&meta= 

Начиная с JDK 1.5, есть java.util.UUID. 

Могу еще предложить такой классец:
 

Tyrex
Там есть класс tyrex.services.UUID если не ошибаюсь.  

commons-id еще есть 

Ок, UUID замутить не так уж и сложно оказалось. Теперь у меня вот какая мысль появилась. Что если я сделаю java-приложение и буду записывать данные через сеть на несколько компьютеров и в несколько баз данных. Представим, что можно подключить к этому делу Hibernate, который будет создавать сам UUID. Но что если мы затем захотим кроме hibernate еще какой-нибудь инструмент подключить, который тоже будет генерить свои UUID. 
Я думаю вот как можно это решить:
1. Сделать супер-класс, в котором будет метод, генерирующий UUID
2. Все классы расширяющие данный супер-класс будут использовать этот метод
Обеспечу ли я таким образом уникальность UUID для всех баз данных? 

Ну дык это зависит от того гарантирует ли тебе алгоритм создания UUID эту самую уникальность и больше ни от чего. К чему вообще такие сложности? Вызывай генератор из Hibernate, будешь получать точно такие идентификаторы, какие он сам назначает.

 

Хорошо, но UUID не самый идеальный вариант для генерирования ID. Рассмотрим другой вариант. Пусть мы будем иметь для каждой базы данных определенный интервал id:
база 1 - от 1 до 1000 
база 2 - 1000 до 2000
и т. д.
Будем тогда просто генерить id в данном интервале от начального значения, используя автоинкремент.
Если будет добавляться новая база данных, то для нее будет выделен новый интервал
Как это лучше реализовать функциями java? 

А чем UUID не устраивает? 


Пишем класс, который хранит регистр серверов (или баз данных или еще чего-то), соответствующие интервалы идентификаторов и значения последних выданных идентификаторов. Поскольку объект такого класса у нас должен быть один на весь пул серверов, то размещаем его в JNDI под определенным именем, по которому все серверы и будут получать объект (как вариант написать удаленный используя RMI, веб-сервисы или что-то еще). 

Но это решение действительно не самое оптимальное по следующим причинам:

• каждый раз когда нужно получить идентификатор, выполняется удаленный вызов (я думаю базы данных не на одной физической машине находятся), а это серьезно скажется на производительности
• думаю таблица, для которой надо генерировать идентификаторы будет не одна и для генерации идентификаторов придется хранить не один объект
• генерация идентификаторов зависит от внешнего сервиса, который может переехать на другой адрес, перезапустится или, наконец, аварийно завершится
• нужно решить вопрос каким образом будет храниться текущее состояние счетчика идентификаторов на случай аварийного завершения или какой-либо другой непредвиденной ситуации.

Здесь подробнее. В самом деле, ведь объект, выдающий идентификаторы не будет существовать вечно, следовательно, где-то нужно хранить текущее состояние (последний выданный идентификатор). Самый очевидный вариант - создать таблицу в базе данных, где будут храниться выдаваемые идентификаторы. Тогда возникает еще одна проблема - каждый раз когда создается новый объект будет выполняться минимум два обращения к БД - сама работа с объектом и получение нового идентификатора. К счастью проблема легко решается. Можно формировать идентификатор из двух частей - хранящейся в базе данных, которая будет выдаваться в начале каждого сеанса работы и резидентной, выдаваемой по принципу инкремента. Тогда обращения к БД будут относительно редки.

Это я описал только часть проблем, которые нужно решить. Так чем такое решение лучше чем UUID, где алгоритм не связан с БД и генерирует вполне уникальные идентификаторы? 

Если количество баз данных фиксировано, то можно использовать генерацию не последовательную, а с определенным шагом. Тогда не надо будет постоянно запрашивать новые и новые диапазоны.

А вообще, в данной ситуации лучше всего UUID.