0 Replies Latest reply on Jun 1, 2005 10:41 AM by Juan Pedro Lopez Saez

    Behaviour when PersistenceManager can't connect to database

    Juan Pedro Lopez Saez Newbie

      Hello everybody.

      I'm using JBoss 4.0.2 and testing a MDB application deployed in the "CMT and Required" way as stated in the wiki. I've also set up a DLQ with MaxTimesRedelivered=0. Message's persistence is handled in a Firebird database.

      The onMessage() method accesses another database when performing its bussiness logic, so XA transactions are involved.

      Everything is working perfectly, just a situation is a little confusing. The matter is the tested behaviour when the persistence database is not available (in my tests it's shutdown) when the container must remove the JMS message from that persistent storage or must update it according to the redelivering policy.

      - When the XA transaction must be committed, the JMS message can't be removed from the queue (I get a "Could not remove message" exception message). The XA transaction is finally rolled back and the message remains in the persitent storage but it's not really redelivered until JBoss is restarted.

      - When the XA transaction must be rolled back, the JMS message can't be updated so it's not possible to send it to the DLQ. The XA transaction is finally rolled back and the message remains in the persistent storage but in this case, it's redelivered until the persistent storage is again available.

      I know this is a quite uncommon scenary but I would like to avoid any kind of redelivery in any situation. The first behaviour, when transaction should be committed could fit my needs but the second one is not so good.

      The only workaround I have figured out is increasing the ConnectionRetryAttempts in my PersistenceManager configuration to delay the redelivery until I can fix the problem with the persistence database.

      I would like to know whether there is a better fix for this situation.

      Thank you very much.