Could stateless session bean use CMP?

[Tom Griffith]

Hello. I have a stateless session facade wrapping an entity bean. What I want to do is query the database in the session facade to obtain the entity's primary key (using a couple of other fields on the current UI as search criteria). Since all the CMP connectivity junk is already configured in web.xml, I was wondering if the session bean could leverage that info? All I can find so far are entity beans using CMP. I know there is no persistence on a session bean, so CMP wouldn't really make sense on the surface, but it doesn't feel right to be coding jdbc into the session facade either. Nor does it not sit well to create another entity for a simple query. Welp, Thank you very much for reading this...I'm going to keep researching.
[ March 18, 2005: Message edited by: Tom Griffith ]

[Valentin Tanase]

Hi Tom,

This might have a simple solution though and it�s build on the premise that you can get the bean�s primary key from the entity bean�s context (see the interface EntityContext). Having said that, I might draft your solution like this:

Build a finder method that returns the bean, passing the couple of fields as the search criteria. Let�s assume that the query uniquely identifies your bean.

The entity bean has a local method that returns the bean�s primary key, calling the getPrimaryKey() method on the EntityContext interface.

SLSB looks up the bean, runs the finder that returns the unique ejb and calls the bean�s local method in order to get the bean�s primary key.

Please let me know if this works for you.
Regards.

[Tom Griffith]

Hi Valentin. It looks as though I could get the handle on the bean simply by building a custom finder method using the passed fields as you outline in Step 1. That would eliminate my theoretical two step process of finding the primary key first and using that to find the entity. Your assumption is right, it is designed so the custom search criteria would be unique. For some reason though, I just feel better about using findbyprimarykey...it seems more portable or something...but then I'd be going througha meaningless loop everytime this bean was accessed...