I just re-ran my tests with my wrapper object synchronized on all methods which call the SFSB and I still see invalid tx id exceptions. Which makes me think this isn't a problem with reentrance into the SFSB, but something with the JMS RA Connection/Session pooling.
--jason On Thursday 23 May 2002 06:28 pm, Scott M Stark wrote: > > 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 _______________________________________________________________ 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
