Session bean design questions

[davout]

I'm building my first complicated EJB application and I've hit a problem to do with declarative transaction settings. It's a subject that to date I've been able to ignore - now I'm hoping somebody can help me with some general guidance.

I'm using the facade pattern where a stateless session bean masks access to underlying CMP entity beans.

One of my more important session bean methods is a lengthy process that involves multiple steps, each step will itself call one or more other stateless session beans. Most of the calls to other stateless session beans are to retrieve information, like 'getEntityX', 'findAllEntityY'.

Occasionally one of these retrieval calls will fail, (the underlying entity may not exist). This is perculating up as a exception which triggers a transaction roll back error in the main process, which is not what I want.

So it seems that I have to declare the transaction settings for each of the retrieval related methods to avoid yes, right?

These leads to two general design questions on stateless session beans that act as facades...

a). How to handle data not found situations.

If I have a session bean method like....

public EmployeeVO findEmployee(String anEmployeeCode);

... what should the method return if the employee does not exist. Should I allow a EJBException to be thrown, or should the session bean method capture the exception and return a null value object result. Both methods are possible, I'm just wondering what is the more popular?

b). Declarative transactions for session bean methods

Should I by default make all session bean retrieval related methods have a 'not supported' transaction setting?

TIA

...... davout

[raist_majere]

To your first question: if your session beans launch not Runtime exceptions and you catch them, the transaction is not rolled back. You can create your own exceptions to get this behaviour, for example...
To question a): deciding on one of the two approaches is subjective... For a good design, your method should throw an application exception you have created, but when throwing and exception (and catching it too) creates overhead on your app, so it's up to you...
To question b): better don't use the "not supported", because if you access these session beans from a web-app, by default I think it uses a transaction, so when you call the bean it will throw an exception... But I think that with my first answer this question has no sense...