George, My reply was in reference to DR only. I have no problems using DBMS for instantiated queues.
Richard Tsujimoto Consultant IT Infrastructure Canon U.S.A., Inc. ( Office: 516-328-5797 2 Fax: 516-328-4588 * Email: [EMAIL PROTECTED] George Carey <[EMAIL PROTECTED]> Sent by: MQSeries List <MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT> 03/30/2008 02:27 PM Please respond to MQSeries List <MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT> To MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT cc Subject Re: New Topic: MQSeries some new Persistence Options What exactly is your point here guys, that having Queue's instantiated in Databases is a bad idea ?? I am missing it. Why are TIBCO, IBM (WAS JQM) and Oracle all giving or have the option of instantiating Queues in databases ... for no reason?? Sure hardware replication should be used, but why not a blend of hardware and software technologies to give the best solution? GTC -----Original Message----- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Sunday, March 30, 2008 08:31 AM To: MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT Subject: Re: New Topic: MQSeries some new Persistence Options yes, agreed. Had a client once that was doing this. With TIBCO, slightly a different beast and approach than the one suggested. but all the same the architecture idea was the same. Against my wishes and my future job stock options prospects I lost the argument and they implemented. A short while after I ran out the back door, their system, I heard from a reliable source, came to a screeching halt. Hours went by before they could get the pig back up. I always like that line..... "Lunacy is doing the same thing twice and expecting different results." Date: Sat, 29 Mar 2008 11:22:16 -0400 From: [EMAIL PROTECTED] Subject: Re: New Topic: MQSeries some new Persistence Options To: MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT Relying on software-based replication for DR purposes is not a good idea. A better solution would be to use storage managed devices that also replicate data to remote DR sites. Richard Tsujimoto Consultant IT Infrastructure Canon U.S.A., Inc. ( Office: 516-328-5797 2 Fax: 516-328-4588 * Email: [EMAIL PROTECTED] George Carey <[EMAIL PROTECTED]> Sent by: MQSeries List <MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT> 03/28/2008 04:58 PM Please respond to MQSeries List <MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT> To MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT cc Subject New Topic: MQSeries some new Persistence Options Is it time (indeed perhaps overdue) that IBM puts forth new options on storage media for persisting messages and logs? Oracle AQ has from the outset used its database as the storage medium. IBM even initially entertained the use of DB2 as its persistence medium but opted for its current flat file structure with proprietary keying mechanism yet I understand still retained logic taken right from DB2 source for its message logging mechanism. Currently competitors such as Tibco (EMS) are in Beta with new product feature to allow messages to be persisted to Oracle or DB2 or theoretically any ODBC, JDBC compliant DBMS. It is being targeted for a May 2008 release. Just call Tibco they will tell you this!! One of the advantages of optionally picking a database vendor for Queue/message persistence is obviously a robust and completely time tested set of solutions (30 years worth) around the many and varied issues relating to DR, HA as well as distributed transactions. Case in point, you have a need for site to site replication for both DR and HA requirements. Your apps send and receive data via ESB and messages can at any point in time be in a state of flux holding 10s of thousands of messages that need to be inserted or updated into sundry database tables. How do you assure that the message queues and databases are in sync with one another on primary and secondary, ..., sites? It clearly is much simpler if the Database and Messaging persistence stores are one and the same, a la Oracle and Oracle AQ. It will soon be the case for Oracle and Tibco or DB2 and Tibco, or AnyODBC and Tibco. What about WSMQ and ????. Maybe WSMQ could keep its legacy persistent store with some added features like circular logging with damaged queue recovery capability!!! But perhaps options for industry standards of ODBC and JDBC databases as the persistent stores will be needed to compete. Also thinking (out of the IBM box) about persistence options, how about looking into the use NetApps like devices in conjunction with concurrent access features like those in the Linux GFS file systems together with some tweaking of the WSMQ servers that might even enable the capabilities of shared message queues for other than the mainframe!! Just some thoughts!! Any feedback is welcome. GTC List Archive - Manage Your List Settings - Unsubscribe Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com List Archive - Manage Your List Settings - Unsubscribe Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com/resources/manuals.asp Test your Star IQ Play now! List Archive - Manage Your List Settings - Unsubscribe Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com/resources/manuals.asp List Archive - Manage Your List Settings - Unsubscribe Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com To unsubscribe, write to [EMAIL PROTECTED] and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
<<image/gif>>
<<image/gif>>
<<image/gif>>
<<image/gif>>
ATT00001
Description: Binary data
ATT00002
Description: Binary data
ATT00003
Description: Binary data
ATT00004
Description: Binary data
