Здравствуйте, secam, Вы писали:

S>Приветствую !

S>Есть такой вопрос... Когда в CMP entity определяется метод EJB Create необходино вернуть уникальный первичный ключ, чтобы контейнер мог создать запись в БД с этим идентификатором.
S>Вопрос в том, как этот идентификатор получить, есть ли какие-то приличные алгоритмы ?

Эта задача подробно описана в книге Floyd Marinescu — EJB Design Patterns. См. главу 5 Primary Key Generation Strategies. Для ее решения там предложено два подхода, которые не зависят ни от СУБД и поддерживаемых ею механизмов генерации уникальных ключей, ни от EJB-контейнера.

Тут прозвучало предложение о том, чтобы вообще не париться с этим и указать класс первичного ключа как Object, вот цитата:

>Вернуть из ejbCreate null. В этом случае контейнер сам занимается генерацией ключа. Правда, при этом
>придется указать тип первичного ключа не Integer, а Object, поскольку контейнер сам займется выбором
>подходяшего (с его точки зрения) типа для ключа. Подробности в спецификации.

Во-первых, любой метод ejbCreate<METHOD> класса компонента CMP Entity Bean согласно спецификации EJB 2.1 должен быть реализован так, чтобы возвращать null, см. главу 10 Entity Bean Component Contract for Container-Managed Persistence, пункт 10.5.2 Bean Provider’s Entity Bean Instance’s View, страница 188:

The implementation of the Bean Provider’s ejbCreate<METHOD> methods should be coded to return a null.[18]

В сноске 18 на той же странице есть следующее пояснение:

The above requirement is to allow the creation of an entity bean with bean-managed persistence by subclassing an entity bean with container-managed persistence.

Во-вторых, в спецификации ничего не сказано о том, что в случае, когда тип первичного ключа указан как Object, то "контейнер сам займется выбором подходяшего (с его точки зрения) типа для ключа". По спецификации это, практически, задача того, кто выполняет деплоймент, поскольку фактическую структуру первичного ключа задает он. Вот что сказано в спецификации на самом деле, см. главу 10 Entity Bean Component Contract for Container-Managed Persistence, пункт 10.8.3 Special Case: Unknown Primary Key Class, страница 222 и 223:

In special situations, the entity Bean Provider may choose not to specify the primary key class or the primary key fields for an entity bean with container-managed persistence. This case usually happens when the entity bean does not have a natural primary key, and/or the Bean Provider wants to allow the Deployer using the Container Provider’s tools to select the primary key fields at deployment time. The entity bean’s primary key type will usually be derived from the primary key type used by the underlying database system that stores the entity objects. The primary key used by the database system may not be known to the Bean Provider.

...

When defining the primary key for the enterprise bean, the Deployer using the Container Provider’s tools will typically add additional container-managed fields to the concrete subclass of the entity bean class (this typically happens for entity beans that do not have a natural primary key, and the primary keys are system-generated by the underlying database system that stores the entity objects). In this case, the container must generate the primary key value when the entity bean instance is created (and before ejbPostCreate is invoked on the instance.)

The primary key class is specified at deployment time in the situations when the Bean Provider develops an entity bean that is intended to be used with multiple back-ends that provide persistence, and when these multiple back-ends require different primary key structures.

В любом случае лично мое мнение состоит в том, чтобы не привязываться к механизмам СУБД, поскольку, как мне кажется, возможны проблемы при использовании различных сочетаний контейнеров и СУБД. Впрочем, если у кого-то есть другое мнение — поделитесь, интересно узнать, что думает народ.