aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes System Assigned Keys and CMP Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "System Assigned Keys and CMP" Watch "System Assigned Keys and CMP" New topic
Author

System Assigned Keys and CMP

Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
How do you take advantage of system assigned keys (i.e. identity columns) in an Entity Bean using CMP? Does support vary by deployment mechanism provided by vendors? If so, which ones support it.
Regards,
Byron Estes


Byron Estes<br />Sun Certified Enterprise Architect<br />Senior Consulant<br />Blackwell Consulting Services<br />Chicago, IL<br /><a href="http://www.bcsinc.com" target="_blank" rel="nofollow">www.bcsinc.com</a>
Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
No takers on this one?
Is it a bad question, or does nobody know the answer?
Regards,
Byron
Karl Laird
Ranch Hand

Joined: Jul 14, 2001
Posts: 67
There are two answers to this one:
a) There is proprietory extensions supported by some application containers that support this (EG: Borland Application Server) in which case it is as easy as editing your xml deployment descriptor.
b) It is kind of a bad idea in general to leave the assignment of the primary keys to the db and greatly reduces you db protability if you do. In general it is usually accepted that if you want autogenerated keys that arent gleaned from the data then this is best handled by another key generation class


The Eagle sneers at the Peacock<p>Systems Administrator<br />OrderWare Solutions Ltd<br /><a href="http://www.orderware.net" target="_blank" rel="nofollow">http://www.orderware.net</a>
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
I agree with Karl on point B.
Could be a better idea to develop a kind of "Java Primary Key Generator" because :
- it increases portability accross App. Servers
- it increases portability accross databases.
- it is quite easy to implement


/ JeanLouis<br /><i>"software development has been, is, and will remain fundamentally hard" (Grady Booch)</i><br /> <br />Take a look at <a href="http://www.epfwiki.net/wikis/openup/" target="_blank" rel="nofollow">Agile OpenUP</a> in the Eclipse community
Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
Thanks for the replies, I understand and appreciate the points you've made, but my background in database developement still drags me back to SA/identity columns.
Portability
What major database do you know of that doesn't support a sa/identity column?
None that I know of...
Key generation algorithms can be a tricky business, what happens if it generates a key outside of the valid value range of your database? The valid value ranges do vary by database, so how portable will it be? Note: You could probably use JDBC metadata to get a range so you could at report the problem in a more friendly way.
Scalability
If your app is running on many servers, the key generator class will either need to be centralized (...and called remotely) or installed on all the servers in which case you'll need a spacial variable (like ip or something) to include in the key algorithm. Most people use time, but time can be tricky if someone resets the clock, DST, or if the server is physically moved to a different physical location into a new time zone (...and the clock is changed). You could enforce a GMT zone regardless of location, but someone could still alter the clock. It's just too frail, in my opinion.
Maintainability
What if you need to update or change the key algorithm? That could be a tricky thing to do and avoid future key collisions. It might require the database to be one-timed. DBMS vendors have spent decades on stuff like this. In this arena most of us are novices.
I hope I didn't come off in an adversarial way because that's not my intent. I do want to investigate all the possibilities and understand what's best in a given situation.
I do sincerely appreciate your opinions and will incorporate them into my personal analysis.
Regards,
Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
Oh...
One other point. Key generators are fine if you are creating a new database which will be supported by your application, but what if you're creating a new front end and business layer for an existing legacy system? Using a key generator class would be very tricky and error prone.
A similar problem would be experienced if you were interfacing with a database that might be updated by applications other than your own. You would either need to rely on the database to assign the keys or change the code of the other applications to use your business logic or at least the key generator.
Regards,
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Portability
An minor actor in the DB market does not support it I think... Its name is...... ORACLE
Scalability
There are some algorithms to garantee unicity.
UUID is one of them, but not the only solution. If you need, we can talk about these algoriithm specifically
Maintainability
Two answers her
No. it depends on the algorithm you've choosen
But yes, if you really change the key structure, it's a lot of job. This is not specific to an auto generated mechanism. The change of primary keys in a DB is tough
[ July 23, 2002: Message edited by: Bill Bailey ]
Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
Originally posted by Bill Bailey:
Portability
An minor actor in the DB market does not support it I think... Its name is...... ORACLE
Scalability
There are some algorithms to garantee unicity.
UUID is one of them, but not the only solution. If you need, we can talk about these algoriithm specifically
Maintainability
Two answers her
No. it depends on the algorithm you've choosen
But yes, if you really change the key structure, it's a lot of job. This is not specific to an auto generated mechanism. The change of primary keys in a DB is tough
[ July 23, 2002: Message edited by: Bill Bailey ]

Portability
True, Oracle doesn't define it within the table, but it provides something called dual.
select field_id_sq.nextval from dual
Which gives me a thought...
One idea might be to have a primary key class that has sql that can be configured via xml. For Oracle you could use a select from dual. Similar selects for max or stored procedures could be called to update key tables and return the next value.
Scalabilty
I am familiar with UUID's and have on ocassion used them, but A UUID is huge. Do you reallyng want to use something like that everywhere, I don't.
Keys just don't strike me as business data, it just seems their creation belongs in the data layer where smarter people than me have devoted their careers to the subject.
Regards,
JeanLouis Marechaux
Ranch Hand

Joined: Nov 12, 2001
Posts: 906
Originally posted by Byron Estes:

Keys just don't strike me as business data, it just seems their creation belongs in the data layer where smarter people than me have devoted their careers to the subject.
Right
Concerning the UUID, it was just an example.
You can also use a stored proc, or an EJB ...
Many design patterns could do the job.
Did you ever take a look at Floyd's book from theServerSide.com ?
About DB portability. Yes Oracle has the sequence. But having another way to do t does not mean you can deploy your application on Oracle easealy.
If it is a concern for you to be DB independant, then the Identity_column is simply not a good solution.
If you're sure you'll always use Sybase for instance, then you don't have to worry about it.
Moreover, do not forget the identity_column in EJB simply does not work do to the EJB spec, which is a little bit fuzzy about it.
If your app server authorizes it, another won't.
Byron Estes
Ranch Hand

Joined: Feb 21, 2002
Posts: 313
Thanks again for the reply.
I'll take a look at the Floyd book.
I have followed (to some extent) some of the key generation discussions on formums at theserverside.com and will continue to monitor those for ideas.
It might be better to only let you CMP bean do updates, selects and deletes. You could add a utility method that could call a stored procedure using JDBC to do the inserts. Granted, the stored procedure would likely change as it was moved from database to database, but that would be manageable. Problem is that is that it's another deplyment step. Hmmmm... guess I'll just have to keep pondering the problem.
Again thanks for your thoughts!
Best,
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16061
    
  21

If you're designing a database specifically for J2EE, I'd recommend not using auto-generated keys.
However, for attachment to legacy databases, sometimes you have to live with what you've been given.
The problem comes up so often that EJB 2 is supposed to be doing things to address it, but I forget if it has made it into the standard. Or for that matter, if that part of the standard has been implemented by anyone yet.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: System Assigned Keys and CMP