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.
