This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Purav, As far as I know (but I haven't verified it), the "ejb-jar.xml" file must contain an entry describing the primary key -- which must be a member of your entity bean, so I guess you can make it anything you want (if your database table has no primary key). But since an EJB container works on the assumption that an entity bean has a primary key, you may discover some strange behaviour! Perhaps a session bean would be more appropriate? Good Luck, Avi. P.S. By the way, don't you love people who call you a stupid idiot because you have a database table without a primary key?
The rationale behind always having a primary key (and especially separate from the data) is that if (when) you need to operate on the table later on, there's no way you can be sure that you'll only delete the one row unless you include all fields' values in the where clause (or first do a select to see that the where clause returns only one record and hope that nobody inserts anything while you're retyping the query for making the update). It would be useful to get an authoritative opinion on this.
Originally posted by Purav Shah: If my table is not normalized, like it is not having any primary key or foriegn key. How can i mention in the entity bean
Keep in mind that what your DB thinks is the primary key for the table doesn't have to be in line with what your container thinks is the primary key. As well, even if you don't have a primary key declared for your table, there probably is a logical primary key. For example, take the following table that details showtimes for movies create table movie_times ( title varchar2(100) not null, venue varchar2(100) not null, showtime date not null, num_seats number not null ) First, note that it's just data (no surrogate keys) being used. One of the main reasons for using surrogate keys is that when one of the venues changes its name, all associated tables must be updated. By giving each row a single-column key -- e.g. id number(10) not null -- you are free to change data attributes without worrying about relations. But anyway, ... So there's no primary key declared on the table, yet if you look at it, clearly the first three columns uniquely identify a row in the table, and that is precisely the definition of a primary key. So in your bean you need to create a primary key class consisting of those three columns. At this point you'll notice another feature of a surrogate key: multi-column primary key classes for entity beans are a major pain in the ass. By using a single column, you just tell the container the name of the attribute in your bean to be used as the PK. You'll need to search for examples of creating a PK-class and using it in your beans and client apps. If you have control of the DB schema, I highly recommend adding surrogate keys. I hope that helped.