My counter argument to this is: your code has to always be prepared to deal
with consequences of servers crashing, networks going down, and other
systems-level problems. A session timeout is yet another systems-level
problem you need to deal with.
If a systems-level problem happens, the container throws an RMI remote
exception. Your client code needs to ALWAYS check for RMI remote
exceptions, whether you're using session beans or entity beans. If a
session bean times out, the container throws a
java.rmi.NoSuchObjectException which is a subclass of
java.rmi.RemoteException, so your code is checking for it by design.
So where exactly does your client code get all bloated by using session
beans? It's already bloated.
-Ed
>From: Imre Kifor <[EMAIL PROTECTED]>
>Here is why I very strongly oppose this unrestrained session bean
>wrapping idea. Any call on a session object can throw an "object
>expired" exception (remember the session timeout?). This means
>that in the client *every* call (to session objects) has to be
>protected and at *any* level you have to support the recreation of
>the session objects. If this is not an artificial complication of
>the client code then I don't know what is.
_______________________________________________________________
Get Free Email and Do More On The Web. Visit http://www.msn.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
