> Yes it should. We have a testcase for this, but how is the timer > interacting with the SFSB, through its remote/local interface?
I have a wrapper object that connects to the SFSB (home.create()) which the main thread uses to send JMS messages, which a timer also uses to send back periodic statistics on. Does each SFSB need its own thread or does it just need to be called synchronously? > 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. Ok, this answers my question above. > If you can sketch the usage more clearly so a testcase can be created I > will do that. I will try... I have a SFSB with a reference to a Queue (and friends) using java:/JmsXA as the factory. This bean is wrapped in a POJO (to handle serialization and restoring the SFSB from HomeHandle). Then a thread is started, which starts up a timer (which is a member of the thread class impl... so each top-level thread has its own timer) which fires every 5 minutes. When it fires it sends a message with the wrapper. Then another object is created, which can start off multipule threads, doing work. When it finishes one of its threads calls back to a listener which uses the wrapper object to send a message. Once the above threads have joined, then a final message is sent back via the wrapper. So all in all there are 3+n threads all using the same wrapper object, which uses the same SFSB remote intf (haven't learned about local intf's yet). This will only happen every 200-300 top-level threads have been created... so I would guess that there is a race condition somewhere... making it difficult to make a test case. I am not seeing any exceptions related to concurrent access to the SFSB at all.. so perhaps the test case could simply be starting n threads using one SFSB and see what happens... > > 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. Perhaps this is a bug due to the Connection/Session pooling which the JMS RA does then? Meaning that the SFSB is not getting concurrently called, though it could be due to the timer (though syncing my wrapper object will tell). If multipule threads entering a SFSB will throw exceptions, then it is likly to be a JMS RA problem? --jason _______________________________________________________________ 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
