Custom Persistence Manager

[amresh]

BACKGROUND

We are using JBoss 3.2.1 with Sybase as the database. We started off using the jdbc2 PersistenceManager (PM) for persisting the JMS messages. We had instances where we lost JMS messages from the queue, as part of investigating the problem we looked at the option of using XA datasource but were unable to justify the cost of upgrade required on Sybase side.


The database for JMS Messages and our application being same we decided to write a custom PM which unlike jdbc2 PM does not suspend the existing JMS transaction and carries out all its functions in the scope of the JMS transaction (container started). Therefore a single commit would provide success / failure for all database operations, including the JMS operations.

The custom PM works fine for basic scenarios such as commit on success, rollback on failed processing, rollback on failed adding/removing etc.

PROBLEM:

We pick a message from the queue, process it (e.g.. insert a row in some table) and then add another message to a different queue. The failed because JBoss adds the message asynchronously, meaning the PM started a new transaction for addition of the message and COMMIT was not called on this new transaction. As a result the database insert was suspended causing the server to hang.


QUESTIONS

1. Is there anyway to ensure addition of messages is handled synchronously?

2. In adding the messages asynchronously (as part of a new transaction) how does JBoss ensure transactionality?

[adrian.brock]

The jdbc2 transaction has nothing to do with the
client transaction. You do not need an XA DB for jdbc2

You do need an XA DB if you want to do two phase rollback
correctly with JMS.

Under what circumstances are messages lost from the queue?

Regards,
Adrian

[amresh]

We have seen messages being lost under the following circumstances:

The application recieves (MDB) a message which it tries to process. If the applciation fails to process the message it starts looping.

We stop the server fix the problem causing exception and restart the server only to find that the message is no longer on the queue.

Unfortunately we have not managed to replicate this in a very predictable manner i.e. in most of the cases the message is still on the queue and gets processed.

I have ensured that we dont have a DLQ set up for that MDB.

Rgds,

Amresh

[adrian.brock]

Is this in an XA transaction where two-phase is required?
e.g. You access the database in the same transaction?

There was a bug in the rollback that didn't set the redelivered
flag if your MDB continues to rollback you get a loop.
The max redelivered is never looked at because the redelivered
flag is not set.

I think this was fixed around 3.2.2RC1 it is certainly fixed in 3.2.2RC3

This shouldn't cause the message to be lost. It should
spot the transaction didn't complete during recovery and put
the message back in the queue.

Regards,
Adrian