> So, this does indeed get interesting... my client code is calling a SFSB which > has a JMS RA, which has the SpySession. > > I do have a timer thread sending back periodic stats with the same SFSB (my > bad) which the main thread uses... but shouldn't the SFSB detect this and > throw an exception about the concurent usage? Yes it should. We have a testcase for this, but how is the timer interacting with the SFSB, through its remote/local interface?
> Shit, my EJB has gotten rusty... only one thread should beable to use a SFSB > at a time... or really one thread per bean in general right... I need to read > the latest spec again. =( There can only be one thread active in a given bean instance. For session beans and mdbs this is guarenteed since an instance is obtained for each request. For stateful beans and entities its enforced by the container interceptors. If you can sketch the usage more clearly so a testcase can be created I will do that. > I can fix my client to sync, but I am wondering if there is something we can > do to make the cause of this problem more obvious for others. > > So, for the spec experts out there, is there something that should be done wrt > the SFSB in this case? This should already be failing. <ejb-2.0, page 76> 7.5.6 Serializing session bean methods ... Clients are not allowed to make concurrent calls to a stateful session object. If a client-invoked business method is in progress on an instance when another client-invoked call, from the same or different client, arrives at the same instance of a stateful session bean class, the container may throw the java.rmi.RemoteException to the second client[4], if the client is a remote client, or the javax.ejb.EJBException, if the client is a local client. This restriction does not apply to a stateless session bean because the container routes each request to a different instance of the session bean class. </ejb-2.0> > And is there any reason why SpySession.sendMessage() should NOT be > synchronized? Yes, Sessions are defined as single-threaded in the JMS spec. If your using this inside of an EJB that should be the case. _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
