Hi, The ExpiryCache is both a publisher and a subscriber, but they are done independently of one another, i.e. publisher is not used within onMessage(). Think of my ExpiryCache as a middleware database cache. EJBs hit this instead of the db directly in a single node, and cache miss and expire messages are broadcasted to ExpiryCache of all other nodes in the cluster. Hence, technically, the EJB execution thread is the one doing the publishing while another execution thread is asynchronously doing the onMessage() callbacks. Since all app servers have pooled threads, and bean/app developers are told not to worry about the underlying thread schema, I'm wondering then how we should deal with this JMS spec-limitation of thread-unsafe Sessions. Seems like this spec was written before app servers were popular or available... Gene -----Original Message----- From: Vikram Rajan To: [EMAIL PROTECTED] Sent: 7/27/01 5:23 AM Subject: Re: [JMS-INT] Threading issues with JMS in an application server hi chuang, >From your description of the ExpiryCache, the relationship between the producer and consumer is unclear to me. Is the publisher used within the onMessage() implementation of the consumer? Or does the publisher function independently of the consumer? Further, do your EJBs publish messages to the topic or do they get invoked by the consumer? If it is the first case, then you are not violating anything from the specification. Read Section 4.4.6, paragraph 2 from JMS 1.0.2 specification. Could you give more details on the expiry cache? I am not sure I have understood how it works. regards, Vikram Rajan > ---------- > From: Gene Chuang > Reply To: A mailing list for discussion of Java Message Service > Sent: Friday, July 27, 2001 5:43 AM > To: [EMAIL PROTECTED] > Subject: [JMS-INT] Threading issues with JMS in an application server > > 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 JMS-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > ======================================================================== === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JMS-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help". =========================================================================== 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".
