PS> IFAIK for EJBs you don't have to release the reference to a stateless PS> bean after performing a call. I guess if I need to release the referenece PS> after the call, the code will have to be written using try {} finally PS> construct which doesn't make code look very clean. Is it the way to go ?
1) I guess that if you _want_ to release something in your worker doFoo() method it is the way to go. Agree, not very nice.
yep, exception handling code can be ugly, but this is a language issue :D
2) Berin, did I get you right that I was wrong in prev. mail and it's preferrable to grab a reference to another component in service() and release in dispose() then to do a lookup() in each doSomething()?
there really is no general rule. It depends on where you want to optimize your application, if at all, on the granularity of your components, etc etc. If you're in need of performance, test both options.
If not, it becomes more of a matter of preference, in which case I like the fact that looking things up in service() makes conceptual sense and results in less lines of code.
Finally, you can delay the choice by doing:
# pseudocode
class MyComp
mySm;
myDep; service( sm )
mySm = sm;
myDep = sm.getMyDep(); getMyDep()
return myDep; doStuff()
getMyDep().helpMe();which isolates the behaviour in getMyDep() and allows you to change it quite easily:
# pseudocode
service( sm )
mySm = sm; getMyDep()
if( !myDep )
myDep = mySm.getMyDep();
return myDep;but means you will have to worry about either performance due to synchronizing the getMyDep() method or the infamous double locking issue, in case you need thread safety.
If yes, then we really shouldn't store anything obtained via a lookup() into the session. A good point!
as a general rule, anything obtained from the ServiceManager or the Context should not be serialized by the component itself. These objects are provided by and the responsibility of the container. If you need to serialize them, you should probably modify the container to handle that.
But remember that as a general rule, there are no truly general rules!
- Leo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
