Re: Relationship between transactions and workflows

Roy Hann wrote:

> Proud Japanese wrote:
>
>> Hi,
>>
>> We are having some disagreement in our team about whether a workflow
>> is composed of transactions (my view) or whether a transaction is
>> composed of many workflows (team leader¢s view). Can anyone kindly
>> comment on this issue? References to webresources and/or books will
>> be welcome.
>>
>> Apologies in advance if this is OT.
>
> In the context of an SQL DBMS the trite answer is that a transaction is
> anything you say it is. That is because only the programmer decides
> where it ends (by doing a COMMIT or ROLLBACK). I shall ignore the very
> knotty question of where the transaction begins...
>
> A better answer is that a transaction should be designed so that it
> consists of a sufficient number of updates to put the database into a
> new consistent state. In my view it should be the minimum sufficient
> number of updates, but that may be an aesthetic preference of mine.
>
> Because a workflow will in general cause the database to be put into a
> succession of consistent states, it seems to me that your team leader is
> incorrect. (I am going only on the basis of your description of his
> view though--which makes no sense at all, so it may be that you have
> misinterpreted his position.)

Just thinking about this a bit more, it occurs to me that perhaps your team-leader is thinking about the ease with which workflows can be abandoned or undone. Perhaps he is hoping that a simple ROLLBACK will be sufficient.

That is naive in general, because a workflow may involve operations that cannot simply be rolled back; they require an entire workflow of their own to reverse them. For instance, it maybe that the workflow causes a work order to be emailed synchronously which in turn results in a cheque being put in the mail, or a hole being dug in the road.

-- 
Roy