Andreas,
>> 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.
>
>The activation/passivation for session beans comes in handy here. You just
>de-activate a session instead of expire it.
Sorry to disappoint you again, but neither the client nor the bean instance
can activate/deactivate/expire a session object. These operations are up to
the container. And the container has to manage resources, so an expiration
needs to be an expiration.
Imre Kifor
Valto Systems
===========================================================================
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".
