Hi, We have designed cluster-enabled data expiry cache for our application running on Weblogic 5.1 and use JMS to provide the dynamic expiry message delivery. Our design is a singleton ExpiryCache (per node) which is used by ejbs. The ExpiryCache instance contains a single TopicSession, a single Subscriber and a single Publisher. Our implementation seems to work without a hitch. However, after perusing Monson-Haefel's JMS book, I came across the "Sessions and Threading" topic at the end of Chapter 2 which states: "according to the JMS specification, a session may not be operated on by more than one thread at a time... if both the publisher and subscriber had been created by the same session, the two threads could operate on these methods at the same time; in effect, they could operate on the same TopicSession concurrently-a condition that is prohibited" OK, so using the example provided by the book, I refactored my ExpiryCache create two TopicSessions, one for publishing and one for receiving. However, since my ExpiryCache sits in an app server with multiple execution threads (for EJBs which will be publishing messages) and multiple JMS execution threads (for onMessage() calls), how can I maintain thread-safety with the publish/subscribe topic session instances? Seems like the only way for me to maintain a individual TopicSessions for each publishing thread is to implement a ThreadLocal cache in ExpiryCache, which will construct a new TopicSession for each execution thread. This seems an execessive burden for a JMS developer working within an app server. And an even more complex issue is how do I maintain session thread-safty for subscription? I have to construct the subscription TopicSession and set MessageListeners from a startup or execution thread, during which I am oblivious to the number or extend of onMessage threads. By the time onMessage is called, it's too late, so this seems like a catch-22 situation! It would seem like the subscription problem is solved if I upgrade to EJB 2.0 and use MDBs as MessageListeners; then I can let the app server deal with Subscriber instance and thread management. But this still does not solve the Publisher instance and thread management dilemma! Is this a legitimate problem, or should I just ignore this spec-breaking issue because my JMS Cache seems to work properly? Gene Chuang Kiko.com =========================================================================== 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".
