David McDonagh

My advice is don't delay and get your certificate.... when EJB 3.0 certificate is released it should not be a big effort for you to upgrade. Anyway here is what Kathy had to say on this topic.
https://coderanch.com/t/159240/java-EJB-SCBCD/certification/SCBCD-or-SCBCD

Arguments and return types for Remote home interface methods must be legal RMI-IIOP types (Serializable, primitive, Remote, collections or arrays .... etc. So I don't think the example you gave is legal.

Not necessary. The Bean provider must specify a primary key type in the deployment descriptor, but they are special cases where the Bean provider may not know the primary key. In those cases he/she must specify the primary key as java.lang.Object and the container will generate the key. See spec section 10.8.3.
Hope this helps :-)

Ya Vijay is correct ..... from the spec P208 "10.9.3 Passivating and activating" the interaction diagram clearly shows that cmp can be passivated after ejbStore() is called.

Thats my understanding also

I think the answer is false. Beans only get passivate before the instance becomes disassociated with a specific EJB object. Therefore ejbPassivate() executes in an unspecified transaction context.

Can you post a sample of your code?

I don't have a complete list, but one question I would ask to see if someone understands or used WebSphere is:
Can you explain your understanding on WebSphere classloading?
It is something that cause me a little heart ache when deploying my app some time back. Here is a link that explains everything
http://submit.boulder.ibm.com/wsdd/library/techarticles/0112_deboer/deboer.html
Good luck

Go to your server perspective and check your server settings that a correct JDBC Provider is configured along with a correct data source. I think you must have something misconfigured in that area !!!

karthik could bksella also use DISTINCT in his EJB QL to only return one record?

From a high level, a CMP is an entity bean, which should really only be used for database transactions i.e. select, update, remove. You most likely would call CMP from other type of beans/Java clients to perform those functions. It is good practice to keep your database transactions away from your application logic.
Stateless Session beans and CMP have different bean lifecycles and different requirements ... do u require a list?

This restriction does not apply to a stateless session bean because the container routes each request to a different instance of the session bean
class.

Here is what the specs mention on this subject P364

====================================================================
The EJB specification does not prescribe how the Container should manage the execution of a method with an unspecified transaction context�the transaction semantics are left to the Container implementation.
====================================================================

so to answer your question accessing other beans / resource managers is left solely to the implementation of the container. The specs give some examples of possible solutions .......

=====================================================================
->The Container may execute the method and access the underlying resource managers without a transaction context.
->The Container may treat each call of an instance to a resource manager as a single transaction (e.g. the Container may set the auto-commit option on a JDBC connection).
->The Container may merge multiple calls of an instance to a resource manager into a single transaction.
->The Container may merge multiple calls of an instance to multiple resource managers into a single transaction.
->If an instance invokes methods on other enterprise beans, and the invoked methods are also designated to run with an unspecified transaction context, the Container may merge the resource manager calls from the multiple instances into a single transaction.
->Any combination of the above.
=====================================================================

I hope this helps !!

WebLogic version 7 supports EJB 2.0. WebLogic 6.1 documentation mentions that it supports a preliminary EJB 2.0 specification ... but I think you would be better off using version 7.

Hi,

I don't have a definitive answer but from my reading of the spec I think it means as you mention that the Directory entity bean will be deleted followed by associated Movie entity beans.
========================================================================
If an entity is deleted, and the cascade-delete deployment descriptor element is specified for a
related entity bean, then the removal is cascaded to cause the removal of the related entity object or
objects.
========================================================================

You have to remember that they are two steps performed by the container when deleting an entity bean i.e. Entity Bean relationship is removed followed by the persistent representation. The container maintains the relationships, so you have to think of it a little different then if you where writing the SQL to remove data directly.
One other thing though � it could be a container implementation on the sequences of data been removed !!! In any case the spec have outlined the outcome from calling entity bean or its accessor method after a cascade-delete.
I hope this helps ��