auto-ID on any J2EE/db combo

Again I'm faced with coming up with a unique record (row) ID for tables. Only this time
I'm not using Oracle or weblogic. There is another solution, but I don't want to toss
the previous solution.
I would really like to come up with something that will always work no matter what the
J2EE server is, or what the relational database is.
It seems that this logic should be within the entity bean, so singletons are out - even
though a synchronized singleton would be the perfect solution.
I'm thinking that an RMI service is the way to go. Yes?

Can't you register the RMI service with JNDI and look it up from the entity bean? This way you can have the RMI service use a singleton to generate the ID and the beans can get it in a distributed environment. If you have a database that has sequences you could use an SLSB (stateless session bean) to retrieve values from the sequence and avoid RMI. There is an article in the latest Java Developers Journal - Linux version that outlines this process I believe.

Check out this link: http://theserverside.com/patterns/thread.jsp?thread_id=4228
The JNDI/RMI approach was the one I was thinking of. While I have used JNDI on several occassions, I am not an expert. I wonder about registering my RMI program automatically with the J2EE server and not having more than one instance if there are multiple servers.

Yeah - I think this may become vendor dependent. I know with weblogic, I was able to write a "RMI monitor", bind it to JNDI and have this behaviour enforce that only one client access it at any one time in a clustered environment. I have not tried this with any other vendors though.

It seems rather dependent on some locking within the database. I'm not sure that mySQL supports that.
I think an RMI solution like you describe will be the way to go.
Can you specify an RMI object in an ear file? Can you initialize JNDI via an ear file?

Yes, the RMI components are included in the EAR file - in Weblogic they are included as startup classes. I've heard to try
and avoid MySQL - it is pretty limited.

I think I've been convinced to drop mySQL.
Some mySQL fans are saying that it will provide what I need for J2EE, but it seems too little, too late.

The problem I encountered with mySQL was that it didn't support transactions.

Apparently, mySQL now has some transaction support, but it sounds like it is a little less than optimal.