For fail over, the batching nature of the journal is not appropriate, you need to send messages directly to the store, either jdbc or file based.
On 29 April 2010 02:51, KRISHNAS <krishna_see...@hotmail.com> wrote: > > > Thanks lot for your reply Gary, > > We have also looked at the 'jdbc statemetns', unfortunately as per DB2, any > statement on the lock table - could cause error, so jdbc statements may not > help (Still we are investigating though) > > So we have to use either specific data source for the locking or we may end > up writing our own file system based locker class. If so, we will > contribute > it. > > We are also looking at the 'Shared file System Master Slave' approach - > which uses the Journal + datasource using <journaledJDBC ... >. There it > uses the File system for locking and permanent DB for persistency. > > But, as per Journal architecture, it may not store all the messages in the > DB (it only persists the left over messages at checkpoint point). But we > want ALL the messages received by the broker should persist in the > permanent DB. > > So is there any way to force the Journal to persist all messages in the > permanent DB (probably by ignoring the check point) or any other approach? > > Thank you, > Krishna. > > > -- > View this message in context: > http://old.nabble.com/How-to-use-the-File-System-for-locking-purpose-and-use-the-DB-for-Message-Persistency-only--tp28391833p28395879.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > > -- http://blog.garytully.com Open Source Integration http://fusesource.com
