This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
All the documentation I see for weblogic6.1 states that WebLogic 6.1 does not support clustering. I was wondering is there a way to get round this, in case of failover. If I have two weblogic servers as part of the cluster, I guess I would use one and the other would be as backup. Then I would create a queue on both to accept messages. If the main server went down, then the second server would take over. The connectionFactory would have the same name on both the servers, although they are in reality separate connectionFactories. I would use the session though as I dont think you can pass sessionm the way you can in servlet session. Can someone tell me if I am on the right track, or have they already solved this problem if so how. Thanks for any help Tony
WebLogic 6.1 does not support JMS Clustering at all. So you will not be able to do things like automatic fail-over. I am sure you could hack something together but we all know how hacks go... WebLogic 6.1 supports distributed destinations. Which basically means you pin the actual JMS destination to a server in the cluster in the rest point to it. This allows you to do things like deploying cluster-wide MDBs and such. It gives location transparency for the destination, meaning clients don't need to know on which server the destination is actually located. This of course means that if the server with the destination fails then you are in trouble. In WLS 7.0 you can configure fail-over destinations but as of yet, the fail-over is a manual process. In a future release automatic fail-over for JMS has been promised. Doesn't do us much good right now does it? Traditionally, JMS has always been the weakest link in WebLogic's clustering technology. If you really need robust messaging you could always use a third-party MOM, like Sonic MQ, which supports JMS Clustering. I find that most projects don't need that type of reliability though. The problem with your suggestion is that there is no way to ensure that messages are not lost. If the provider goes down then any of the messages stored are not going to be migrated to the new provider. [ December 01, 2002: Message edited by: Chris Mathews ]