Post by Roy HannPost by Proud JapaneseHi,
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