Good Question, But I feel that as for Session beans, the container takes care of creating an identity for the bean with BMP and this will be used by the Handle also. and so calling on remove by Primary key class throws an Exception.. and same as a BMP the handle can be useful (for serialization and invoking over other JVMS etc) as long as the BMP exists in the memory... Need to look at ths specs once..before I can say for sure.
posted 16 years ago
Rajan, I think that this question is specific to entity beans, because there is no Persistence of any kind in Session Beans. So I would think that the fact that Raj asks about BMP ( Bean Managed Persistence ) automatically tells us we are dealing with Entity Beans with Bean Managed Persistence. If this is the case, the Sun App Server will not pass the Bean on the J2EE compliance test, if it lacks the primary key. Herbert.
posted 16 years ago
Yes guys, I am talking about bean Managed Persistence (BMP) mapping to a table with duplicate records or without primary key
posted 16 years ago
Raj, My feeling is that you HAVE to have a primary key for a proper implementation of BMP according to the J2EE spec. After all, a good database design will yield a normalised database that will call for a primary key and eliminate redundancies in the tables. Herbert.
Hi guys, I was not around to note the comments made...well to start with I know what Raj (Jindal) was talking about. I was referring to the scenario in case there is not PrimaryKey for the Entity Bean with Bean Managed Persistence. well I admit my wrong that the container provides an Identity (Handle) for the Entity Bean with BMP without a PrimaryKey (as in the case of the Session beans). well we need to provide a Primary Key. Well Rajs requirement can still be achieved, what the Container needs is a PrimaryKey class and not a Primary Key ( in terms of RDBMS concepts). This is particularly possible because we are using Bean Managed Persistence, we need to create our PrimaryKey class. lets not forget that we have to override all the lifecycle methods ourselves and the Container does not offer any guarantee of contract... in case there is no primary key in a table you can still implement the functionality by providing a business level constraint that will allow us to find a unique record. like a unique key spanning more than one column. if you still insist that the we cannot find the unique record with the column attributes, then your life cycle methods should return a collection of the Primarykey Class or generate a unique key in the create Method and return that PrimaryKey Class. if this is not possible, then it would be a nightmare for the companies who want to upgrade to EJBs using BMP and implementing the CMP would be out of question. but another question is would there be a design where people wont force unique key constraints, that is remote....but hey it is not impossible either just for your reference here is a quote from the ejb 1.1 sepcs
infact Raj has asked a thought provoking Question and I think I will workout an example on these lines and confirm asap...
JavaBeans v1.1, Final Release Application Assembler�s responsibility 11/24/99 242 Sun Microsystems Inc. Entity bean�s primary key class. If the enterprise bean is an Entity bean, the Bean Provider specifies the fully-qualified name of the Entity bean�s primary key class in the prim-key-class element. The Bean Provider must specify the primary key class for an Deployment descriptor Enterprise Entity with bean-managed persistence, and may (but is not required to) specify the primary key class for an Entity with container-managed persistence.
[ April 02, 2004: Message edited by: RajaniKanth Bhargava ]
I don't even know how to spell CIA. But this tiny ad does:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop