Jim,
I'm not sure how of what you believe the problem is. First I thought
that we were talking about stateless session beans. I believe that
earlier postings established that that the client shouldn't be aware
of or care what the server is doing. As users of EJB servers all we
want is for our clients to have their requests serviced in a timely manner.
I can't speak for the Inprise implementation of this requirement but
GemStone offers a multi VM solution. Not only will GemStone reap
session beans, it may reap VMs. The client is never aware of this
activity. And.. I don't believe this is a violation of the spec.
Kirk
-----Original Message-----
From: Marc San Soucie <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Monday, January 17, 2000 11:36 PM
Subject: Re: Stateless Session Beans
>James Cook wrote:
>
>> I guess the real question involves the server-side EJBObjects. Marc was
>> stating that Gemstone (correct me if I'm wrong) destroys these resources
>> after a suitable timeout period.
>
>I was stating that an EJB server, on request from an administrator
>using a technique such as a configurable timeout, should be able to
>eliminate client-specific artifacts that are "out of date". Some
>folks interpret the EJB spec to say that client references to
>stateless session beans are never "out of date". The spec doesn't
>say this, but it's certainly one possible interpretation.
>
> Marc San Soucie
>
>===========================================================================
>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".
===========================================================================
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".
