Anyone have any experience with asynchronous saving?

This is a brief explanation of what I am trying to do:

We have a pretty straightforward system, we do normal saves, fetches, etc. of our business objects.

For certain tables we want to keep a history/audit log. So essentially we will have a mirror image of each of the tables we want to track. During the save routine in the DataAccessAdapter, we will "interrupt" the save process and identify whether the entity requires a write to a history table. If it does, we will create the history entity and save that as well.

What I would like to do is add the history entity saves to some sort of message queue, since the main thread (and the user) should not have to wait for the history/audit entities to save. Also, these additional saves are critical, but not "high priority". If they happened ten minutes after the "main" save, it would not pose a problem.

I have no experience with asynchronous processing or message queues (which I know are very different concepts). I'm not even sure I'm using the right terminology.

So, I guess I'm looking to be pointed in the right direction on:

1. Saving entities in a separate thread.
2. Saving entities via some sort of database message queue.

I'm not sure I need both--if I can achieve #2, I might not need #1.

Any and all insight would be appreciated. Thanks!

We have the same type of log tables, but we update them through triggers. These inserts are very fast because there is almost no index on these log tables...

castlejoe wrote:

We have the same type of log tables, but we update them through triggers. These inserts are very fast because there is almost no index on these log tables...

Thanks for the reply.

We want to avoid using triggers where possible. While I personally think triggers get a bad rap in a lot of cases (mostly when people mis-use them), I try to use them only when I absolutely need to. One of the (many, many) things I really like about LLBL is that you can extend the DataAccessAdapter class to mimic trigger behavior.

Other thoughts?

If the history is that critical.

Doing saves in different threads will allow for the possibility of having records updated but not in the history, as the case of system crash, an exception thrown...etc.

The best way I see it if they are that critical is to have them in the same database transaction, and I think it won't have that implication on the performance.

Anyway it's a trade-off