1

Say we have a view page where users perform actions in multiple steps, some of these actions would involve DB operations with transactions (the snippets are in pseudo-code like from):

View 1:
    Step 1:
        ...

    Step 2:
        ...
        Call ActionX

    Step 3:
        ...    

ActionX: # can be called from different points in the view
    ...
    Begin Transaction
    DB ops
    End Transaction

Say we want to log the user progress in the view (or save some states) in a persistent manner in the DB, so that if the program/app is interrupted we can re-establish the state to the last user action inside a view:

View1:
    Step 1:
        ...
        Logger.log('view1-step1-done')

    Step 2:
        ...
        Call ActionX
        Logger.log('view1-step2-done')

    Step 3:
        ...
        Logger.log('view1-step3-done')

Now ideally, we would want to have the persistent logging and the DB based transactional actions to be both done in the same DB transaction, because we don't want to create an inconsistent state where an action is performed but is not reflected in the log state, or vice versa.

The question is: how to achieve the said goal with minimum inter-dependency and SOC. Some suggestions for example:

View 1:
    Step 1:
        ...

    Step 2:
        ...
        Begin Transaction
        Call ActionX    # begin/end transaction statements will be removed from ActionX
        Logger.log('view1-step3-done')
        End Transaction

    Step 3:
        ...

Don't like this because the handling of transactions belongs naturally in the action itself.

Or, another one:

View 1:
    Step 1:
        ...

    Step 2:
        ...
        Call ActionX (logMsg='view1-step3-done') 

    Step 3:
        ...

ActionX (logMsg): 
    ...
    Begin Transaction
    DB ops
    Logger.log(logMsg)
    End Transaction

Don't like this one either. The log message handling doesn't belong in the actions.

Improve this question
2
  • As an aside to your direct question you are making implementation decisions based on knowing the log goes to the DB but if a file based log were used instead would not be needed. This seems to imply you have something else wrong as well.
    – Sign
    Commented Dec 28, 2012 at 14:13
  • Thanks. I'm actually storing states rather than logging, into a key-value table. It's a form that inputs config for future actions, being divided into groups and upon finalizing a group, changes are made to db tables and a summary state is saved to help reconstruct the form in case of interruption. I used logging in the example because it makes it easy to present the problem - apologies if that caused unclarity. Nested transactions seem reasonable, and splitting states as proposed by @GlenH7 makes good sense too.
    – Basel Shishani
    Commented Dec 29, 2012 at 1:50

2 Answers 2

Reset to default
2

The primary guidance for this question is to separate out the responsibilities.

It appears that you are trying to link an Action's transactional state with the Log's transactional state, and I think that's a mistake. Record the Action changes based upon the Action. Record the Log status based upon the resulting (returned) status. If the Action succeeds, then Log a success status message. Likewise, if the Action failed, then Log an error message to that effect.

Since your log messages appear to be indicating status from the Views, then it is the Views' responsibility to handling the logging.

If the log messages are related to the internal aspects of the Action, then the Action should take the responsibility of logging.

Please keep in mind that those two positions are not exclusive of each other. You might find that you need to log both the Views' progress as well as internal aspects of the Action. At that point, you would have both areas (Views and Action) making logging calls.

Improve this answer
1
  • 1
    +1 Log Statuses at a specific instant, Start, End, Error, Ect
    – Morons
    Commented Dec 28, 2012 at 20:54
1

A nested transaction would work if your database supports them.

View 1:
Step 1:
    ...

Step 2:
    ...
    Begin Transaction
    Call ActionX    # begin/end transaction statements will be removed from ActionX
    Logger.log('view1-step2-done')
    End Transaction

Step 3:
    ...

ActionX (): 
...
Begin Transaction
DB ops
End Transaction
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.