Asynchronous Processing and Transaction Completion

  • We have a Application that is nearing completion. Its a Componment-based application that is designed from VB6 and SQL Server. This Application has about 100 components.

    The issue for me is when an End User creates a Policy for example, this immediately goes into a Queue and the application is available to create other policies, etc. Another process reads the Queue for available work and performs the work. This work may be many Asynchronous Tasks. (Asynchronous processing.)

    My questions is when dealing Asychronous Processing, how do you rollback the initial Transaction if there is an error in one of the Asynchronous tasks?

    This seems very costly to me.

  • Can you walk me thru you application and data model. Not sure what you are looking for.

    Shot in the dark here.

    You mention a queue which is where you new policyies are stored until completed, is this a queue table, if so then add a marker with something to uniquely identify the applications transactions so how. As you add ned items you mark each the same. You process on the SQL side marks each as done but there should be a field for batch completed also. So as each is done by the server side process you mark that item with the identity value given in the main table and mark the line completed. From the client standpoint when a set of transactions have been submitted you then mark the batch completed. Now the server side process will need extra logic to check if any specific failure occurrs it goes back and removes all the bad processes (you may have to use the client to help here), then you notify the client so the person is aware of the issue. Beyond that make sure you build a lot of the business logic in SPs on the server side so as you come across failures you can change the code to account for them before they can occurr, so the client can be stopped and notified a correction is needed.

    If I am wrong please give me a better insite into what you are doing.

    "Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)

  • This is whats happening:

    1. End User creates a new Policy.

    2. This gets put in a TBL_USER_ACTION table.

    This is a Queue table. Could be alot of Policies queued up here.

    3. There is a TBL_EVENT_TRIGGER table that every 30 seconds goes to the TBL_USER_ACTION table and gets the queued items. This table uses Meta Data tables and creates the plan to complete the task(s). There could be MANY tasks here including:

    (a) go to the mainframe for data needed

    (b) Inserts data into SQL Server

    (c) Print the document

    (d) Email the document

    etc.

    4. This then goes into the TBL_PENDING_EVENT table for processing.

    5. There is also a TBL_EVENT_LOG_RESULTS table.

    - The only Synchronous task is Step 1.

    - The rest are Asychronous tasks.

    Questions:

    What should be included in a Transaction here?

    How should a Rollback work here?

    (with these Asychronous tasks)

    Where does MTS fit in this picture?

    PLEASE give details!!!!!!

    Also explain what you meant by putting alot of Business Logic in the Stored Procedures.

    Thanks.

  • Doesn't apply for you situation, that as I said was a shot in the dark. You are headed somewhere else. I will have to think the logic out as I have not done anything like this. Maybe someone else will have an answer and sorry I cannot promise ou one. When I have time I will take look and try to maybe build a transaction logic here.

    Now here are my current thoughts.

    In regards to policies, will policies be tied together? If they are then you will definently will need a precompletion table that keeps track of steps done that the data can be dropped from, otherwise you will have no way to build the associations to track the problem.

    If not then you should be using BEGIN TRANSACTION, ROLLBACK, and COMMIT during the policy processing for the entire process not any one section.

    If a print or email failure should cause undo of all then you will have to store a copy of the work detail including data and such in another table and when done move to the final table. Otherwise build logic to redo these actions until work, if cannot complete write details to a table for both and notify administrator or server operator who can correct issue.

    Let me know if this gives you any ideas as to what to do. You logic seems a bit to much to work without staging tables if all or nothing is what you need to meet.

    "Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply