Relationship between transactions and workflows
in [Theory]
|
Prev: P and NP are sets; I wonder if category theory (which puts structure on sets) and information theory would be useful in proving P != NP.
Next: Regarding philosophy of RESTful architectures
From: Proud Japanese on 16 Jun 2010 19:17 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 leaders view). Can anyone kindly comment on this issue? References to webresources and/or books will be welcome. Apologies in advance if this is OT. Thanks, Hayato
From: Roy Hann on 17 Jun 2010 08:01 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.) -- Roy
From: Roy Hann on 17 Jun 2010 08:11
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 |