Hi Adrian, > > So my question is, is there any harm or reliability issue for JMS during > > the time when 2 JMS nodes are up at the same time? > > > > This would not work, you would end up with two servers > modifying the same persistent store each with different ideas > about what is the next message id and transaction id. > Most likely this would fail with some primary key constraint > violation or data not found.
Alright, I had a feeling that this would not be a good scenario :) . None the less the scenario with the spilt partition I described in my former mail is real. We experienced this sometimes in our production environments. If this happens with the singleton MBean in place for JMS failover one would be in trouble. > The only way to make this work would be to have cluster safe > unique keys (such as a GUID) and force jms to restart on any > newly elected master (even if it was previously a master) > to "merge" the db changes as the cluster partitions are merged. Is this hard to implement? I don't want to offend anyone here but is it really worth it? Would it not be better to provide a truly transparent clustered JMS implementation? As far as I know you guys are already working on something for jboss4. How far along are you and are there any plans to back port to 3.2? Regards, Sebastian _______________________________________________________ This message is for the named recipient's use only. It may contain sensitive and private proprietary information. No confidentiality is waived or lost by any incorrect transmission. If you are not the intended recipient, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Sakonnet Technology, LLC and its subsidiaries reserve the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity. Unless otherwise stated, any pricing information given in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation. ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
