Topic: Transaction Scope and why so many problems

[Jeff H]

I have never understood why people have so many problems with transactions are how they get so nested, so thought maybe I would ask.

Other than an subscribing to an event the outer boundaries of your code will always start and end with a method marked command attribute.

So why would ever start a transaction in a method that is not a command?

If using a modeless dialog etc... you can send a string to command with 500 prompts and send those 500 values and be executing or done with command before the person even realizes they have let their finger off the mouse.

Was wondering what I am missing

[Keith Brown]

Other than an subscribing to an event the outer boundaries of your code will always start and end with a method marked command attribute.

Not quite true.  The programs that i do maintenance on have one command that opens a palette.  There is no transaction in that command.  Then when the user hits a button or fills in some information then some action is done on the model using a transaction.  No command to start the process.

[Jeff H]

Other than an subscribing to an event the outer boundaries of your code will always start and end with a method marked command attribute.

Not quite true.  The programs that i do maintenance on have one command that opens a palette.  There is no transaction in that command.  Then when the user hits a button or fills in some information then some action is done on the model using a transaction.  No command to start the process.

The last statement was CYA(and not very clear) about sending a command instead executing from ApplicationContext but I do exactly what you mentioned and easy to maintain as well.

[kdub_nz]

Keith,

Wouldn't the palette button raise an event and thus quality as

Other than an subscribing to an event ...

I need coffee or sleep, so I may have missed something.


added
as an aside Jeff;

Once someone starts doing weird stuff with transactions it muddies "Clarity of Intent" which has ramifications.
So, I don't think you're missing anything.
....[/  just a noise from the bleachers]

[mohnston]

An example of the need for a transaction not associated with a command might be a "Draw" button on a UI.
Nothing happens until the user clicks the button. There is no command associated with the "draw" method because it relies on data from the UI. You wouldn't want to start a transaction until it's needed.

Or did I miss your point?

[kdub_nz]

An example of the need for a transaction not associated with a command might be a "Draw" button on a UI.
Nothing happens until the user clicks the button. There is no command associated with the "draw" method because it relies on data from the UI. You wouldn't want to start a transaction until it's needed.

Or did I miss your point?

For me; No you didn't miss the point.
... and I believe that is the consensus.

Transactions and Document locking are really pretty simple.