Can anyone give me an advice which id Generator to use within EJB's?

increment: The documentation gives the advice 'Do not use in a cluster', but we have a cluster -> NO

identity and sequence: Depends on the database, but I want to be database independent! -> NO

hilo: Documentation says 'Do not use this generator with connections enlisted with JTA or with a user-supplied connection' but I use EJB's so I have JTA! -> NO

uuid.hex: Could be used, but char(32) keys are quite inefficient. -> YES

So the only solution to me seems an unefficient uuid.hex generator. As listed in a previous post the HILO EJB doesn't seem to work using Hibernate within MBeans!

Can anyone give me an advice?
Thx Rene!

Sorry, is the question to trivial or is it too complicated to answer. I really need a solution until monday!

I wonder what other J2EE developers did? There's a lot of literature about using Hibernate in Web applications but only few literature on how to use it within an managed architecture?

I wonder what the advice from the Hibernate developers would be? The uuid.hex generator is not a popular approach as told by Gaving King in 'Hibernate in Action' page 91 as varchar primary keys consume more database space than numeric keys and are marginally slower.

But again, how can numeric primary keys be achieved without using proprietary features like identity and sequence that are additionally slow because the need two database transactions?

Please help!
Thx Rene

They don't, use a sequence if your database supports it. Thats what they are made for.

I have the same doubt. And I hate sequences, it makes you be bound to database specific problems. I'm searching for advice on that topic. Looks like everybody is just trying to ignore the existence of this problem.
Even a ejb stateless solution is not good: I may not want to use EJB at all and still have a managed set using servlets.
I was thinking about implementing an alien generator that goes directly in a datasource and gets a new connection. This goes beyond hibernate, is a weak point in the J2EE-JCA "mono connection" way of work.
I'd like to see a good reply on this topic.