That seems crystal clear to me. Without the spec changing, it seems like
the burden is on me to syncronize access to the session bean reference.
Off the record this seems kind of silly, it should really be a
deployment option whether to reject, or else syncronize, concurrent
access to the bean. Either way you achieve the primary design goal,
which is to prevent concurrent access.
Bryan
Scott M Stark wrote:
> It says must as I read it. It is putting the burdon of correct usage on the client
> rather than the container.
> 6.11.6 Non-reentrant instances
>
> The container must ensure that only one thread can be executing an instance at any
>time. If a client
>
> request arrives for an instance while the instance is executing another request, the
>container must throw
>
> the java.rmi.RemoteException to the second request.
>
> Note that a session object is intended to support only a single client. Therefore,
>it would be an
>
> application error if two clients attempted to invoke the same session object.
>
>
> ----- Original Message -----
> From: Bryan Field-Elliot
> To: [EMAIL PROTECTED]
> Sent: Thursday, April 05, 2001 11:27 AM
> Subject: Re: [JBoss-user] Stateful session beans, concurrency, and blocking?
>
>
> Regarding the EJB spec --
>
> In the scenario in which their is an attempt at concurrency by a Stateful Session
>Bean client, does the spec _specifically_ say,
> "throw an exception"? Or, does it say, "don't allow it" (but leave a gray area
>whereby a container might choose to block caller #2
> until caller #1 is finished)? Either scenario seems fine with me, it seems like it
>should be up to the developer to choose a
> strategy, but (as comic Dennis Miller says), "that's just my opinion and I could be
>wrong".
>
> Bryan
>
>
>
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-user
>
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
